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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
