Remote widgets, the next steps

[Fabrizio Montesi]

On Tue, Sep 29, 2009 at 4:30 PM, Rob Scheepmaker <
r.scheepmaker at student.utwente.nl> wrote:

> I never really considered the case of implementing a native
> Plasma::Services
> in jolie script since that could get a bit complicated anyway, considering
> the
> access control/message signing, plus additional overhead like the fact that
> we
> should send over valid kconfigxml describing the parameters.


Message signing and access control shouldn't be too hard to code: I'd like
to write some sort of standard Jolie library for handling Plasma services
and to distribute it with Jolie. Could you provide the workflow specs?
(describing them here is fine)

We had some work on generating kconfigxml automatically from Jolie interface
files, see
http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/tools/jolie2plasma/
Only problems are w.r.t. certain data types (which I see you already know by
your explanation in the following).

Also, publishing
> a Plasma::Service using a different technology (like as a SOAP service)
> would
> be tricky since the access/control and message singing would make this SOAP
> service quite complicated to use
>

Well, a lot of SOAP services in the industry there have very complicated
specifications on how to access them. I don't think anybody would kick us
for some security parameters that need to be added to messages. :-)


> I mostly considered the case of accessing something like a SOAP service
> from
> plasma as something seperate, where we could leverage jolie, but need to
> use a
> different approach. In that case we would want some wsdl to jolie converter
> for example, since it would be a pain if a developer that just wants to use
> a
> web service needs to do that by hand. And a wsdl to configxml convertor,
> since
> Plasma::Service need to provide valid configxml. And a seperate Service
> implementation that doesn't do any access control stuff and just calls
> operations on the service, but this would be a relatively small and trivial
> class to make. I could at some point add a function to access manager to
> access any non native plasma service through a Plasma::Service. If/when (?)
> there are converters to help us with the wsdl, it should be very easy ...
> both
> to implement, and to use.
>

This is true, but if we provide a way to use the loadEmbeddedJolieService in
MetaService so to load custom Jolie scripts and see them as a
Plasma::Service I can at least access SOAP services by making a Jolie
script. In a lot of cases making a Jolie script for accessing a SOAP service
is easy, and there are hard cases in which I would like to use a Jolie
script even if I had all the automatic converters because there could be a
necessity for some additional orchestration (security protocols, handshaking
etc...) which Plasma doesn't support.

For the future tools, we would just need a WSDL2Jolie converter, since we
already have Jolie2Plasma (which converts a Jolie interface to a kconfigxml
service descriptor).


> The problem of streaming the parameters is not entirely solvable. The
> parameters passed to any Plasma::Service are a QVariantMap. I could
> obviously
> put every element of the map as seperate child node, but they're still
> QVariants, and those will need to be serialized/deserialized.
> I could use the 3 native sodep types: string integer and double directly,
> but
> this doesn't solve the issue for all the types out there, just for some of
> the
> most common ones.
>

I suggest we go this way:
- if a parameter can be cast to a sodep data type, convert it;
- otherwise, serialize it.

Nevertheless, maintain the separate child node structure. This way we
already have a mostly working implementation (I imagine most parameters in
Plasma are integers, strings, doubles and booleans?) and I can start adding
sodep data types appropriately as we see necessary.


>
> > Another problem I've seen is that the remote widgets framework makes use
> of
> > special operations like startOperationCall, and others for checking
> access
> > control. There is nothing wrong with this, but then for performing
> "normal"
> > operation calls you are passing the operation name in the message data,
> not
> > in the message headers. This breaks interoperability with everything
> >  because you've got two levels of operations, the special one and the
> >  normal one, whereas services have just one. A quick solution for this
> >  would be to make these operation names standard and reserved for
> >  Plasma::Service, or (better) to hide them behind a specific resource
> name
> >  (e.g. "PlasmaControl").
>
> Yeah, I suppose I could put the actual operations in the operation name
> instead of the startOperationCall parameters.
>

That would already be a great step forward, yes.

What I'd like to get working first is to, at least, be able to implement
local (yes, local) services in Jolie. By doing so I would already gain a lot
of power, for example a plasmoid could load this Jolie service using
loadEmbeddedJolieService in MetaService and I could use this Jolie service
to orchestrate whatever distributed application in a network, hiding the
complexity from Plasma.
Orchestrating a distributed application could be something complicated
(multiparty p2p session) or simply accessing your GoogleMail. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20090929/74cd07de/attachment-0001.htm