Hello,

As you might know, I'm working on the network transparency in plasma GSoC 
project. I've been drafting up the required API. Once I've implemented some of 
the code it will most likely need a round of API review or two, but I wanted 
to discuss if my design is in the right direction. See 
http://imagebin.ca/view/hQ-56dc9.html for an overview. It's not 100% complete, 
and I already noticed a flaw just 
when I wanted to send this mail (access makes mores sence as static function 
in RemoteDataEngine analogue to Service::access), but it should give an idea.

1. Network enabling Plasma::Service
This is the core of the project. All other services (moving plasmoids to other 
machines, providing dataengines and such), will be implemented as 
Plasma::Services. Main advantages are consistency, and it keeps all JOLIE 
related stuff contained to Plasma::Service.
To allow Plasma::Services to be published, A publish (and unpublish) method 
will be needed. I was thinking of two optional parameters: Protocols and 
ServiceAnnounceMethods. Protocols will default to just NativeProtocol (not 
SODEP, because that's an implementation detail), but this will allow plasma 
services to be provided as SOAP or maybe other stuff that will get supported 
by JOLIE in the future. Think about the possibilites: using the nowplaying 
dataengine on your personal website through SOAP for example :). 
AnnounceMethods will for starters just be ZeroConf through DNSSD (well, we'll 
probably default to none, because announcing only makes sense in the case of 
Applets/Containments, not for engines and such imo), but in the future we can 
allow other ways of service discovery.
For accessing a remote service I'll implement a RemoteService class with two 
static access methods: one for native plasma services, and one for stuff like 
SOAP services. The first one just needs a location and protocol, the second 
one the name of a jolie script (which can be looked up in some standard kde 
directory or even in the package structure in case of a scripted package), and 
a QMap to provide values to initialize that service. So for accessing a SOAP 
service, you'll just need to provide a jolie script that can do that (which is 
quite easy, just take a look at http://www.jolie-
lang.org/language_tutorials.php, the invoking web services example), and other 
stuff that might be required (city? username/password? stuff like that, 
depending on the service), and you'll be able to access the web service! Now 
if there would just be a way to automatically generate jolie script from WSDL, 
things would be amazing :p
Furthermore, RemoteService will need a location getter and setting to indicate 
where the remote service is located. It might be usefull though to have a 
QList of Locations and add/removeLocation functions so we can do 'multicast', 
as will be required when multiple machines connect to the same dataengine. For 
this multicasting we can implement a simple jolie service that allows 
registering multiple peers that will all receive every message received by it.
Accessing services this way can take some time (we have to wait for a response 
for the other side which might still be asking the user to authorize your 
request), so just like ServiceJobs, we use a KJob subclass so you can monitor 
when the service is ready to be invoked.

2. Add authorization
To do authorization, there needs to be a way to securely identify the caller. 
We can accomplish this by including an url (that of the sender) and a digital 
signature as parameter to every sodep message. Every plasma instance will be 
required to run a PublicKeyService. The first time a message from a certain 
url is received, the PublicKeyService at that url will be requested a public 
key. All public keys collected this way will be stored, and used whenever a 
sodep message arrives to validate the message's signature.
QCA can be used for generating keys and creating signatures. QCA is already a 
dependency for quite some kde apps.
With this in place, Plasma::Service can reliably identify the url of the 
caller (also nice that I can't subscribe somebody else's computer to a 
dataengine this way :p) and ask AccessManager (probably a global static class) 
to authorize the url for that service. AccessManager can then use a 
KNotification to ask permission:

rpi.student.utwente.nl would like to access the nowplaying widget.
[deny] [allow] [always allow]

When authorization is successfull (or not), the signal authorizationFinished 
will be fired, and an requested ServiceJob will be started.

3. PlasmoidTransportService
Now we'll need a service that allows remote computers to access an applet or 
containment. Depending on whether or not it's a scripted plasmoid we can allow 
a remote machine to receive a package, if required. In all cases we can 
request the applet's current configuration. In applet we can add a static 
access method (analogue to that in RemoteService) that receives a location of 
a PlasmoidTransportService, requests it's config, a package if the applet is 
not installed locally, instantiates the Applet and set's engineLocation (in 
the UML just a location, though we might have to make it a QMap<QString, 
Location> so we can have different engines used from different locations).

4. DataEngineServices
Implement 2 services that allow dataengines to be used remotely. 
Applet::dataEngine will use DataEngineManager::access to access a remote 
dataengine when engineLocation is a remote location. The RemoteDataEngine 
class is just a DataEngine that also includes a location, and sends the 
necesarry messages to the DataEngineProviderService when used. Each 
RemoteDataEngine will also publish a DataEngineConsumerService so it can 
receive dataUpdated messages from the remote engine.

I would also have to add a service to easily allow applet's to sync their 
config() with other machines that are remoting that applet, but let's start 
with implementing this.
Looking forward to some feedback on the design. If there's stuff I forgot 
about discussing in this mail, please ask. Changes are I've already given it a 
thought but just forgot writing it down here.

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