Re: P-services interface in Strawman OPES Charter

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