GSoC proposal draft: network transparency.

[Rob Scheepmaker]

I've mentioned my interest in this GSoC project before. Now I've made a first 
draft of a proposal for GSoC. I'm looking forward to feedback:

Network transparency in Plasma.
Introduction
The goal of this project is to make some parts of plasma network transparent 
with as end goal the ability to:
move applets and activities over the network
share applets and activities between multiple computers
have applets be able to use services and data engines on remote computers

Use cases
Alice is a teacher on a school where they use computers as a learning aid. She 
has set up all computers in the classroom to display a single shared activity 
in plasma. Now Alice can modify this activity on her computer depending on 
what she teaches that day, and all the children immediately see changes she 
made on their desktop as well. Because this activity is shared, a lot of 
applets also sync smoothly: whenever she modifies the text in a certain note 
applet for example, all children will immediately see this change. Alice can 
use this mechanism to give children exercises through the blackboard applet, 
and she can monitor the children's progress.

Bob's desktop PC is connected to his stereo, and he often uses that PC to put 
on some music. He doesn't want to have to walk to this PC whenever he wants 
to, for example, skip a song. He publishes the "now playing" applet that is 
already on the desktop of his main PC. He picks up his wifi enabled smart 
phone, and in the add widget dialog on his phone (which is of course running 
plasma) he selects this published applet from the list of  applets and 
containments that are published on the network. Now the exact same "now 
playing" applet appears on his phone. He can use this applet to skip songs on 
his main computer, or to see what song his main computer is playing.

Charlie just got a new notebook. He would like to have some of the same 
activities he has created on his other PC on his newly installed notebook. He 
publishes these activities to the network, and adds those activities on his 
notebook. Note the difference between this use case and the previous one in 
that in this use case, Charlie will want to use his the local data engines and 
services of his notebook, instead of being connected to the data 
engines/services from his main computer. 

From here on, I will refer to the behavior needed by Charlie as copying (it's 
just that: a copy of an applet/activity and it's configuration), while the 
behavior needed by Alice will be referred to as sharing (changes to an applet 
or activity's state/configuration on one computer will also affect instances on 
other computers, and they even share the same data engines and services).

Requirements
This section contains an overview of the components that are needed.
Network transparent Plasma::DataEngine and Plasma::Service. I will use Kevin 
Otten's services framework to make this work easier. This library is currently 
still a work in progress, but it's nearing completion and will most likely be 
completed once GSoC starts. The API of this library will be very much like 
Qdbus, only network transparent. Using this library I will create services 
that allow to use Plasma::DataEngines and Plasma::Services from a remote 
location through a RemoteDataEngine and RemoteService class.

Ability to announce shared applets and activities on the network, most likely 
through zeroconf (using KDNSSD). If time permits, other ways to publish 
activities could also be implemented, like telepathy tubes or GHNS.

Ability to send applets and/or activities over the network:
A service that allows people to obtain shared activities or applets. This 
service should send the applet (in case of a packaged, scripted applet), and 
applet or activity's configuration.

The dataEngine function should return a RemoteDataEngine pointing to the 
correct location in case of a shared applet. Applet needs a property for this 
to indicate where all desired engines and services are located.

A way to synchronize changes between multiple shared applets. It should 
require only very little effort for applets to publish changes to all shared 
applets, or receive changes from other shared applets. Again, I will use Kevin 
Otten's library to make this easy.

Containment should use this synchronization api to synchronize applet 
positions between shared activities.

Publishing and accessing activities and applets should be something the user 
can do through the GUI easily. I will add the necessary bit's to the plasma 
GUI, most likely actions in context menu's for publishing, and a network 
browser in the add widget dialog for accessing.

The security implications will need to be thought trough. We will need some 
some way of authenticating systems that are allowed access to published 
applets or activities.

Timeline
April 20 – May 22: Community bonding period, experiment with Kevin's library, 
draft and discuss the required api. Draft and discuss the interfaces for the 
required services.

May 23 – Juli 6: Implement network transparency for DataEngines and Services. 
Implement publishing engines and services. Implement framework for 
synchronization and some test case to test this behavior.

Juli 6 – August 3: Implement a service to send an applet or activity over the 
network, and use the synchronization framework in containment to allow for 
activity sharing, and improve one or more applets to synchronize their 
changes: good candidates are notes applet, blackboard applet. Add simple GUI 
options for copying or sharing applets or activities.

August 3 – August 16: I'll be on vacation.

> August 17: Polish the results, write a tutorial for techbase.

About me
I'm a student in computer science at the University of Twente in the 
Netherlands. I'm currently in my fourth year of studying computer science. 
I've been active in plasma development for more then a year now, part of which 
was last years summer of code. Because of that experience I'm quite familiar 
with both the Qt and the Plasma API. I also have experience in designing and 
discussing new API with a group of developers.
I'm hoping to get accepted for GSoC again. My previous work has been very GUI 
oriented, and this would be a chance for me to gain some experience in service 
oriented architectures. I really like working together with the plasma 
developers on such an exciting piece of technology. I'm also convinced  that 
this would be one of those innovative features that would really set plasma 
apart from any other workspace/widget engine out there. 


Regards,
Rob