So I beleive, it becomes mandatory to explicitly define 'how to
interface external modules to P?'
Mandatory only if by "external modules" you mean "OCP-speaking OPES
services". Interfacing with them is required for OPES framework to be
complete. Interfacing with something else (e.g., a Java class
implementing a content adaptation service, C library implementing
P/HTTP module, or an ICAP service) is not required/mandatory.
Are we on the same page?
No, I want to differ slightly here.. Specifying tht interfaces with OCP-speaking
OPES services is mandatory (as you agree). However, I think we should also
specify the interfacing with external module , atleast to some extent. One of
sample use cases is invocation of non-OCP services as we discussed in the
mail... Having said that, I realize that it is not possible to define/specify
to interface all the different types of modules (types based on authored
Java, Python, P) onto P. But, I guess we need to define a list of mandatory
that the module needs to provide in order to interface with a P rule set. The
way in which the external module interfaces with the P runtime/core
(language/runtime issues) is left to the implementor. These API's could be
reflective in nature, used by the P runtime (at the minimum) for validating a P
program. Whether to make it available to the rule writer or not can be debated
later, I guess.
Do you agree?
thanks & regards
Alex Rousskov wrote:
On Wed, 14 Jul 2004, Geetha Manjunath wrote:
How about supporting non-std interfaces as additional module?
For example (pl forget the syntax for now):
// Invokes the std OCP service, serviceA - OCP service supported by
import ICAPService // A special module that supports invoke method on ICAP
Sure, that's the intended feature/beauty of P design! If we get the
abstraction level high enough, 3rd parties would be able to add all
sorts of modules doing all sorts of interesting things, while P
programmers will not even notice.
Do we agree that defining such additional modules or even defining an
interface to plug such additional modules into a P interpreter is
outside of our current scope?