[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: P work in new charter
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.