Remote widgets, the next steps

[Fabrizio Montesi]

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

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

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

Cheers,
Fabrizio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20090929/d9fb69e0/attachment.htm