Remote widgets, the next steps

[Rob Scheepmaker]

On Tuesday 29 September 2009 10:53:41 Fabrizio Montesi wrote:
> Hi everyone,
> 
> I've studied the code of the Remote Widgets implementation and I'd like to
> discuss some internals. Most of the following (if not all) could be already
> known, anyway.

Cool, I could use some more peer review :)

> If I understood the implementation correctly, the parameters for operation
> calls to a remote Plasma::Service are serialized as a byte array, which is
> then deserialized on the other side. This works just fine between a Plasma
> instance and another Plasma instance, but won't work with other
>  technologies (because the message isn't properly structured, so for
>  example a SOAP service would just see a stream of bytes inside the SOAP
>  body instead of an XML tree of parameters). Moreover, if I wanted to use a
>  Jolie script to implement a complex Plasma::Service that, i.e., implements
>  a peer to peer multiparty game/chat/something I couldn't do it for the
>  same reasons. What needs to be done is to create the message by reflecting
>  the parameters structure, so one child node for each parameter.

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. 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
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.
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.
So in short: accessing native plasma:services from something other then plasma 
is tricky because of the access control, accessing something not native 
plasma::service from plasma would be easy to add support for, depending on the 
state of wsdl -> joliescript and wsdl/joliescript -> configxml converters.

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

> Last, the current implementation is just using tcp sockets and sodep, but I
> think that's obviously known. :-)

hehe, yeah it is :p
 
> Cheers,
> Fabrizio.
>