Network transparency in plasma, first API draft
r.scheepmaker at student.utwente.nl
Wed May 20 19:38:21 CEST 2009
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.
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).
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.
More information about the Plasma-devel