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
the
sample use cases is invocation of non-OCP services as we discussed in the
attached
mail... Having said that, I realize that it is not possible to define/specify
how
to interface all the different types of modules (types based on authored
language -
Java, Python, P) onto P. But, I guess we need to define a list of mandatory
API's
that the module needs to provide in order to interface with a P rule set. The
exact
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.
Examples:
M.moduleHasFunction(functionName)
S.serviceHasParameter("a")
M.getModuleAttrList()
S.isOCP()
Do you agree?
thanks & regards
Geetha
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):
Services.invoke(serviceA,1,2);
// Invokes the std OCP service, serviceA - OCP service supported by
default.
import ICAPService // A special module that supports invoke method on ICAP
services
ICAPService.invoke(serviceB);
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?
Thanks,
Alex.