Re: P-services interface in Strawman OPES Charter

Geetha,

	I understand your motivation better now, thank you. I wonder
whether we can use the same generic approach to describing "loadable"
modules and services. This would match the "service is a module"
approach we talked about just before P work got frozen awaiting for
new charter.

	Do you have a proposal of what to use for publishing
declarations of module interface? P? WSDL? Something else? Can you
point us to documented examples of similar interfaces for other
languages?

Thank you,

Alex.


On Mon, 19 Jul 2004, Geetha Manjunath wrote:

>
> Pl see my comments inline...
>
> Alex Rousskov wrote:
>
> > On Fri, 16 Jul 2004, Geetha Manjunath wrote:
> >
> > > Examples:
> > > M.moduleHasFunction(functionName) S.serviceHasParameter("a")
> > > M.getModuleAttrList() S.isOCP()
> >
> > Hmm... Are you proposing some kind of "symbol table" API that would
> > specify what objects the module exports, by name? So that the core
> > interpreter could check that all names in a rule set are defined
> > without actually loading/executing the module?
>
> That;s right. Infact, this is pretty common in object oriented runtimes
> which allows dynamic loading of modules (like Java, Python) - this is what
> is often referred to as "reflection API".
> One of the uses (as you mention) is validating whether a P program is
> correct . This is however very important - since the validation can be
> done just once, at the time a P program is loaded onto the OPES processor
> - rather than everytime a P program is executed ( request/response)
>
> > If a module exports an object called "request", will the API also
> > define that the "request" object has "headers" and "body" sub-objects?
> > But the API will not define how an interpreter can actually access
> > "body" or even "request", right?
>
> Yes - that is implementation dependent. The OPES processor is free to run
> a P runtime/core engine that was developed  in any language - and the
> specifics of this interfacing actually depends on the languages chosen and
> so on -- which is clearly out of our scope.
>
> > What purpose would that API serve other than code validation?
>
> See my comment above.
> In addition, specifying the mandatory API's that need to be supported by
> an external module - allows us to clearly and completely specify the
> requirements of a P runtime engine - for somebody to go ahead and
> implement in different ways. At somepoint, it will also enable P modules
> to be used on multiple implementations of P runtime - which is one of the
> implicit goals of OPES (I beleive).
>
> Thanks and regards
> Geetha
>
>