Fair enough!
Alex Rousskov wrote:
On Thu, 1 Jul 2004, Markus Hofmann wrote:
Geetha Manjunath wrote:
I beleive and agree with others on the need for local services for
peformance reasons. If the mechanism is an indirect way of
registering local services that is fine - but then we should
clearly specify means of interfacing external modules to P. [ does
that add to the scope of P? ]
All you need is calling a local service from within "P" - just as
you would call a remotes service, it's just running on the local
machine. Alex elaborated in this in his previous email.
I suspect Geetha is talking about a standard mechanism/interface to
register a local service (always implemented in something other than
P) with P interpreter so that it becomes accessible from P rules. To
do that, we need to standardize service interface. I do not think we
are ready for that now, but it could be our future work.
For example, if we document how an OCP/HTTP service can be contacted
based on P "service call" code, then any OCP/HTTP service (local or
remote) can be registered with the P interpreter and used from P
rules. This would be a P-to-OCP mapping of some sort.
Similarly, if we document how a Web Service can be contacted based on
P "service call" code, then any Web Service (local or remote) can be
registered with the P interpreter and used from P rules. This would be
a P-to-WSDL mapping of some sort.
I think it is important to keep these future integration tasks in
mind, but I wonder if the first stable version of P spec should be
done before we start documenting the above interfaces? The risk is
that first P implementors will have to come up with some glue of their
own, and that glue would be difficult to standardize post-factum. On
the other hand, I doubt we have enough cycles to document these
interfaces now, as a WG activity.
Alex.