Hi everyone,<br><br>I&#39;ve studied the code of the Remote Widgets implementation and I&#39;d like to discuss some internals. Most of the following (if not all) could be already known, anyway.<br>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&#39;t work with other technologies (because the message isn&#39;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&#39;t do it for the same reasons.<br>
What needs to be done is to create the message by reflecting the parameters structure, so one child node for each parameter.<br>

<br>Another problem I&#39;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 &quot;normal&quot; operation calls you are passing the operation name in the message data, not in the message headers. This breaks interoperability with everything because you&#39;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. &quot;PlasmaControl&quot;).<br>
<br>Last, the current implementation is just using tcp sockets and sodep, but I think that&#39;s obviously known. :-)<br><br>Cheers,<br>Fabrizio.<br>