Remote widgets, the next steps
r.scheepmaker at student.utwente.nl
Tue Sep 29 16:30:24 CEST 2009
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
More information about the Plasma-devel