'Remote widgets, the next steps'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: kde-panel-devel
Subject: Remote widgets, the next steps
From: Fabrizio Montesi <famontesi () gmail ! com>
Date: 2009-09-29 8:53:41
Message-ID: e20638690909290153l32d39031ue980dc4026dbe3a3 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

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.

[Attachment #5 (text/html)]

Hi everyone, I&#39;ve studied the code of the Remote Widgets impleme=
ntation and I&#39;d like to discuss some internals. Most of the following (=
if not all) could be already known, anyway. If I understood the implemen=
tation correctly, the parameters for operation calls to a remote Plasma::Se=
rvice are serialized as a byte array, which is then deserialized on the oth=
er side. This works just fine between a Plasma instance and another Plasma =
instance, but won&#39;t work with other technologies (because the message i=
sn&#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 Plasm=
a::Service that, i.e., implements a peer to peer multiparty game/chat/somet=
hing I couldn&#39;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&#39;ve seen is that the remote widgets framework make=
s use of special operations like startOperationCall, and others for checkin=
g access control. There is nothing wrong with this, but then for performing=
 &quot;normal&quot; operation calls you are passing the operation name in t=
he message data, not in the message headers. This breaks interoperability w=
ith 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 f=
or this would be to make these operation names standard and reserved for Pl=
asma::Service, or (better) to hide them behind a specific resource name (e.=
g. &quot;PlasmaControl&quot;). 
 Last, the current implementation is just using tcp sockets and sodep, b=
ut I think that&#39;s obviously known. :-) Cheers, Fabrizio.

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[prev in list] [next in list] [prev in thread] [next in thread] 