Re: P-services interface in Strawman OPES Charter

> > Won't that info be available while  "discovering a service" ie., your
> > (following) first addendum item  ?
> > - Defining how available services become known
> >           to the rules language interpreter? (At least
> >           OCP-speaking services)
> >
>
> Good question. It all depends on the result of service discovery. If
> the result of service discovery is service ID and IP:port pair, then
> no. If the result of service discovery is service ID, IP:port pair,
> and complete service profile, then yes. I assumed the former context.

I assume the latter context ;-) Atleast that is what is done for  web service
discovery.

> In many cases, the service interface will be hard-coded in some OPES
> processor configuration file, avoiding any dynamic discovery.  The
> question is, do we want to be able to write a P interpreter that only
> understands one (standard) service interface description (possibly
> supplied by the service vendor) as opposed to supporting multiple
> non-standard description formats (also possibly supplied by service
> vendors)?
>
> And, even if we declare standardizing service interface description
> out of WG scope, we still must document how an invocation call in P is
> translated into OCP commands, right?

How about supporting non-std interfaces as additional module?

For example (pl forget the syntax for now):
Services.invoke(serviceA,1,2);
// Invokes the std OCP service, serviceA  - OCP service supported by default.

import  ICAPService // A special module that supports invoke method on ICAP
services
ICAPService.invoke(serviceB);

Geetha