JOLIE and Plasma: status and discussion

[Fabrizio Montesi]

Hi everyone,
this is a recap mail about the current status of the integration of JOLIE and 
Plasma, so that everyone can jump in and to make discussing it easier.

As you can see in SVN, the JOLIE integration layer didn't make it for KDE 4.2. 
That's to avoid cluttering with Plasma's API when the project is committing to 
binary compatibility. What we'll do instead is:
- create a libplasmajolie project (in extragear?);
- put the integration layer there, extending Plasma::Service with something 
like Plasma::PublishableService;
- release it along with KDE 4.2.x, so that people can start studying and using 
it asap;
- merge Plasma::PublishableService with Plasma::Service in KDE 4.3 trunk.

That allows us to test the API and the quirks of the integration with complete 
freedom w.r.t. Plasma's compatibility until KDE 4.3, giving also the 
possibility to write plasmoids exploiting that API as soon as possible.

Basically, what we already have is the following:
- the Jolie modifications to satisfy Plasma's needs (this is in Jolie's SVN);
- MetaService: the Jolie service allowing for service exposure and access (see 
http://techbase.kde.org/Projects/Plasma/Services);
- QtSodep: a Qt library implementing SODEP, a fast&clean binary protocol for 
communicating with Jolie (/branches/work/~ervin/sodep);
- a reference implementation for the wrapping of MetaService in a library: 
metaservice-java (this is in Jolie's SVN playground);
- perhaps something more on aseigo's side, but still incomplete?

What we need to do is:
- wrap addRedirection and loadEmbeddedJolieService in a couple of 
Plasma::Service C++ methods (simply translating the code from metaservice-java 
will suffice, it's just using the C++ classes of QtSodep instead of what I use 
there);
- use those methods to implement service exposure and service access;
- for service exposure, we also need to open a local (unix) server socket in 
order to make a Plasma::Service able to receive messages from the network via 
MetaService;
- make a nice API;
- make it possible for the programmer to automatically expose and access 
DataEngines.

For some documentation about MetaService's interface:
http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/support/metaservice-
java/src/joliex/metaservice/MetaService.java?view=markup
http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/playground/metaservice/metaservice.iol?view=markup


The main problems right now are to review a good API and the automatic 
exposure/access of DataEngines. So everything below here is under heavy 
discussion, comments are really appreciated. Also, please ask anything you 
need about these arguments, I've just jumped in plasma-devel so I'll read 
mails sent here. =)
I don't code C++ since some time, so I'm probably missing some details (like 
QString instead of QString& or something...), please bear with that. Also, I'm 
not a KDE coder, so I could say some terrible things on using KJobs etc.

Whenever we ask MetaService for publishing or accessing something, we're 
calling its addRedirection operation. So, internally, we'll probably have 
something like in metaservice-java, i.e.:
KMetaServiceJob* addRedirection(QString resourcePrefix, QString location, 
SodepValue protocol, SodepValue metadata)

we return a job so that the GUI doesn't get stuck waiting for responses from 
MetaService. When MetaService successfully adds a redirection, it publishes it 
under its own location. Suppose that MetaService's location is 
"socket://localhost:8000/" and you're publishing something with resourcePrefix 
"Time", then you'll have that your redirection will be available at this url: 
"socket://localhost:8000/!/Time". If there is already a "/Time" redirection, 
MetaService will append a number, e.g. "/Time-2". MetaService notifies this 
choice in its response, so KMetaServiceJob should make this information 
available.
KMetaService job should be private.

---
--- 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.

---
--- 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.net"));
Plasma::ServiceAccessJob *s = 
Plasma::Service::access("socket://www.webservicex.net:80/geoipservice.asmx", 
protocol);


---
--- DataEngine exposure
---
API:
Plasma::ServicePublishingJob Plasma::Service::publish(DataEngine* dataEngine)

Example:
Plasma::ServicePublishingJob *j = Plasma::Service::publish(myDataEngine);

How it works:
we create a Plasma::Service class for wrapping a DataEngine (here I use 
Plasma::Service::DataEngineWrapper), so that we can use 
Plasma::Service::publish() and Plasma::Service::access() on it.
DataEngineWrapper should then forward any request to its own DataEngine.

Alternative:
I don't know about that DataEngine::serviceFor() method. Could we use that and 
do something like Plasma::Service::publish(dataEngine->serviceFor(..)) ?
That would be cleaner, but is there any limitation to do just that?

---
--- 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())?
2) handle it all privately in a single method in Plasma::Service just for 
service exposure.

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();


2)
API:
Plasma::DataEngineAccessJob* Plasma::Service::accessDataEngine(QString 
location, SodepValue protocol)

Example:
Plasma::DataEngineAccessJob *dataEngine = 
Plasma::Service::accessDataEngine("socket://192.168.1.20:8000/!/MediaPlayer", 
SodepValue("sodep"));