JOLIE and Plasma: status and discussion

[Fabrizio Montesi]

On Saturday 22 November 2008 02:39:34 Aaron J. Seigo wrote:
> On Thursday 20 November 2008, Fabrizio Montesi wrote:
> > ---
> > --- Service Exposure
> > ---
> > Example of service exposure:
> > Plasma::Service *s = ...; //Some plasma service obtained in some way.
> > Plasma::ServicePublishingJob *j = s->publish();
> >
> > Here Plasma::Service::publish() is a wrapper for:
> > addRedirection(d->name, my_unix_server_socket_location,
> > SodepValue("sodep"), SodepValue());
> >
> > where my_unix_server_socket_location should be a Jolie location pointing
> > to your open unix server socket where you're accepting sodep messages,
> > e.g. "localsocket:/tmp/mysocket"). KServicePublishingJob should allow the
> > programmer to know if the service has been published successfully or not.
>
> this looks good; only thing we need to think about now is access control?
Affirmative. Is there any technology we can use that comes to your mind or we 
have to do everything from scratch? PolicyKit perhaps?

> > ---
> > --- Service access
> > ---
> > API:
> > Plasma::ServiceAccessJob* Plasma::Service::access(QString location,
> > SodepValue protocol)
> >
> > Example of service access to a Plasma::Service published in another
> > computer: Plasma::ServiceAccessjob *j =
> > Plasma::Service::access("socket://192.168.1.20:8000/!/Time-2",
> > SodepValue("sodep"));
> >
> > Example of service access to a soap service with a protocol parameter:
> > SodepValue protocol = SodepValue("soap");
> > protocol.children("namespace").append(SodepValue("http://www.webservicex.
> >ne t")); Plasma::ServiceAccessJob *s =
> > Plasma::Service::access("socket://www.webservicex.net:80/geoipservice.asm
> >x" , protocol);
>
> my first thought is that we need to get rid of socket://192.168... etc.
> having to know how to create a Plasma::Service URL is probably a bit much.
Definitely, agreed.
> what are the necessary bits? hostname, port and path? we should be able to
> pass that in as a KUrl and have it assemble the correct path with the
> needed !'s etc there?
A JOLIE location is a URI, and is composed by the following parts (i couple 
them with the example parts):
1) The communication medium: "socket"
2) The path specific to the communication medium, whose format depends on (1):
"192.168.1.20:8000/someStuff/someOtherStuff.php?querystring=whynot&otherparam=etc"
3) The resource path, which starts after the !: "/Time-2"
Mmh, I have to think a bit about this and to have a look at QUrl/KUrl. We 
could also make a Plasma::Service::Location class (possibly extending KUrl..) 
providing simple constructors and enumerations (we should provide an 
enumeration for the various communication mediums: Socket, LocalSocket, 
etc..).

> also, instead of SodepValue's with strings (no compile time checking), i'd
> rather expose an enumeration that is mapped internally to the proper
> protocol string.
I agree (and extended that idea to mediums, above).

> perhaps going so far as hiding "SODEP" as a detail and
> just calling it the NativeProtocol (and having that as the defult)?
Yes, so that in the future we could even change the "NativeProtocol" 
internally if the need arises. Following this line, we should make sure to 
hide any "Sodep" keyword from the API.

> > ---
> > --- DataEngine access
> > ---
> > We have two options:
> > 1) make it possible for any DataEngine to wrap a Plasma::Service (is this
> > possible? if so, it looks as the best option to me); could this open
> > other possibilities other than dataengine access? perhaps this reasonment
> > could then be applied also to DataEngine exposure (i.e.
> > DataEngine::toPlasmaService())?
>
> it should be possible to publish DataEngines in the same way we can publish
> Services. in the background it would be using a Plasma::Service, but that
> would be an implementation detail and one the user wouldn't need to see.
>
> this should probably be added to DataEngineManager, and requests from
> published services can pass through it via the MetaService. so when a
> Service is published, it woul tell DataEngineManager to listen to the
> service for publishing requests.
>
> > 1)
> > API:
> > DataEngine* Plasma::Service::toDataEngine()
> >
> > Example:
> > Plasma::ServiceAccessJob *j =
> > Plasma::Service::access("socket://192.168.1.20:8000/!/MediaPlayer",
> > SodepValue("sodep"));
> > ...
> > DataEngine* myDataEngine = j->service()->toDataEngine();
>
> this particular usage would be wrapped in DataEngineManager to make it
> ++transparent and so that we don't need to expose things like
> toDataEngine();
So, if I understand correctly:
DataEngine* DataEngineManager::access(same_params_as_Plasma_Service_access);
?

I overlooked DataEngineManager, I've just read it now. Yes, it makes sense to 
put the dataengine access magic there.