Re: P-services interface in Strawman OPES Charter

>  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.