Re: P work in new charter
Geetha Manjunath <[email protected]>
| Newsgroups | gmane.ietf.opes |
|---|---|
| Message-ID | <[email protected]> |
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.