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