From kde-devel Tue Mar 18 14:19:37 2014 From: Jinesh K J Date: Tue, 18 Mar 2014 14:19:37 +0000 To: kde-devel Subject: GSoC Proposal : Cloud support for KDE application settings Message-Id: X-MARC-Message: https://marc.info/?l=kde-devel&m=139515241623999 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============5167790820618985192==" --===============5167790820618985192== Content-Type: multipart/alternative; boundary=001a11c27be0e30d9c04f4e239e7 --001a11c27be0e30d9c04f4e239e7 Content-Type: text/plain; charset=ISO-8859-1 Hi Devs, I have submitted my final GSoC proposal. Full proposal contents are given below. I really wish if some mentor could look into it and have their opinion. Thanks: *Organization:* KDE *Short description:* One of the problems that many users deal with on a daily basis is maintaining a consistent configuration on multiple desktops. Often whenever we make a configuration change in one, we have to go around on all the other systems to make the same changes manually at some point in future. This project aims to implement configuration synchronization to enable a seamless and consistent experience for a KDE user across his/her KDE desktops. *Name:* Jinesh Jayakumar *Email Address:* jineshkj@gmail.com *Freenode IRC Nick:* jinesh *IM Service and Username:* Google/jineshkj *Location (City, Country and/or Time Zone):* Syracuse, US. NY ------------------------------ *Proposal Title:* Cloud support for KDE application settings *Motivation for Proposal / Goal:* Technology and how it is used has changed dramatically during the last 10 years. There are more people online in the internet, using a multitude of heterogeneous devices. One of the problems that myself and my friends face is dealing with configuring multiple desktop systems in a consistent manner. I myself have two laptops and a desktop (in college) with KDE installed. I believe the case is not very different for most of you out there. Often whenever I make a configuration change in one of these systems, I have to go around on all the other systems to make the same changes manually at some point in future. To make my point clear, let me introduce a few simple use cases. For example, when I add a new RSS feed to Akregator, I need to ensure that I manually add the same in all my systems. Or take the case of adding a new bookmark to rekonq or konqueror. Consider the case when I changed a keyboard shortcut and having to make the same changes in all other systems. It would definitely be a lot simple if all the configuration changes get synchronized automagically over internet? Now consider the case where you plan to reinstall your OS. Or, change from one Linux distribution to another. Or maybe you just want to use a desktop at your friend's home for doing some leasure time coding. Wouldn't it be a lot nicer if you could just login and synchronize your KDE session to get the same look and feel of your own system. This project aims to provide a seamless and consistent experience for any user across different KDE installations. *Implementation Details:* Before I delve into the details of my new design, I like to explain how (most) KDE applications store their configuration data. The KDE core library provides all KDE applications with the KConfig ( http://api.kde.org/4.12-api/kdelibs-apidocs/kdecore/html/classKConfig.html) interface that provides a transparent means to store application configuration data. The data gets stored in an application specific directory under $HOME/.kde4/ folder in an INI-type file format (by default). Although an application could use custom formats (ex. XML is used by Akregator to store feed URLs) by storing raw text, vast majority of KDE applications use the default format. In the new design, I intend to add few additional features to the KConfig interface about which I shall explain a bit later. To begin with the new design, I intend to first write a simple KDE service that starts automatically when the user logs into their KDE session. This service takes care of synchronizing application configuration data present in $HOME/.kde4 directory. The service itself would be enabled and configured by the logged in user using its KCM module from systemsettings application. In order for this service to synchronize and authenticate in the cloud, user provides his/her identity.kde.org credentials. Once the KDE service authenticates the user with identity.kde.org, it connects to the cloud service to fetch updated application configuration stored in the cloud. Authentication credentials will be stored in KDE Wallet. The downloaded configuration is then stored in a local temporary store and then later provided to their respective KDE application for further processing. This processing itself could happen in two ways: 1. If the application is presently running in the system, it would receive a signal "configChanged()" from its corresponding KConfig object. This signal when captured by the application would receive the new KConfig object based of configuration data stored in the temporary store. Once the application receives this object, it takes the decision as to what changes to accept and how to accept. We would let individual app developers decide how they like to process the data. 2. If the application is not running presently, it will obtain the new configuration as a temporary KConfig object, the next time it starts running. It would happen the same way as above. Those applications that do not wish to use signals would be presented with a polling mechanism using a new member function isChanged(). If the application decides the save the new temporary KConfig object as the application's, then it calls another member function changeConfig(const KConfig& new_config); . As you can see here, we have added a new signal and two member functions to the KConfig class. The preferred way for KConfig to monitor for configuration updates from cloud is by watching changes to its temporary configuration directory using the portable KDirWatch interface. Now, when an application modifies its configuration using KConfig, the KDE service would receive a notification, again through KDirWatch interface. The synchronization service then performs a cryptographic hashing (MD5 sum) of the new configuration data to check for any changes really made to it. If the checksum differ from that present in the cloud, the new configuration is propagated to the server. The whole process of synchronization works exactly like how a version control system like Subversion works - before a change is pushed into the server, the synchronization service and the corresponding KDE application need to be consistent with updated configuration from server. While I work on the synchronization service, I would also work on having a web service running on identity.kde.org or similar server to provide an API, possibly REST, for the synchronization service to connect to. Although I am a fan of Ruby, I don't mind using PHP or Python in the server side. I will also provide a simple system tray application (similar to the one provided by Dropbox) from where we could quickly control some of the functionality of the synchronization service. Since there are hundreds of applications in KDE, it's impossible to get this feature implemented in all of them. But, to provide a proof-of-concept, I would like to change two applications - Konqueror/rekonq and Akregator - to have suport for new cloud infrastructure. Konqueror would be updated to synchronize bookmarks and Akregator for feeds. Since this is going to be a major feature, I would rather target on KDE Framework 5. All software written, except for the cloud server, would use C++ and Qt5/KF5. Github would be used for source control and project management. IRC and mailing lists will be used for communication with other community members. Let me also list down a few things that could be worked on in future after the GSoC. User will be able to maintain different configuration profiles - like home, work, etc - choose a profile to load. The service could be used to easily backup and restore configuration data using cloud storage. A KDE user would be also able to log in to the server's web interface and observe or even control his KDE sessions from the cloud. He/she could use an encryption key to encrypt all data stored in the server - KGpg could be used for help. He/she would be able to link his KDE.ORG account with a third-party data storage service like Dropbox, Google Drive, OwnCloud, etc for storing of configuration data. He/she could possibly use the KDE server more like a Bit Torrent tracker and store the data just in his/her systems. Maybe in future, even the KDE server could be avoided and use a de-centralized distributed hash tables to store the data. Possibilities are infinite, usefulness is immense and time is ticking. I believe KDE should introduce this feature before any other commercial or open-source desktops do. This feature could very well be a unique selling point for KDE. *Tentative Timeline (in weekly intervals until 2 weeks after the end of GSoC):* 9 May : Project Start 16 May : Implement KCM module for KDE service configuration (esp. enable/disable, identity.kde.org credentials, choose applications to sync). 23 May : Implement the Synchronizer KDE service to autostart on KDE login and authenticate with identity.kde.org 30 May : Implement a basic configuration storage facility in the server. 6 Jun : Support for using KDirWatch to monitor for local configuration changes inside $HOME/.kde4, calculating checksum and find changes. 13 Jun : Support for using KDirWatch to monitor for configuration updates from cloud. 20 Jun : Alpha version of Synchronizer service 27 Jun : Alpha version of KConfig functionality 4 Jul : Alpha version of cloud server functionality 11 Jul : Modify Akregator to support synchronization 18 Jul : Modify Konqueror to support synchronization 25 Jul : Beta version of all the above modules 1 Aug : Alpha version of system tray application. RC1 release of all other modules 8 Aug : Beta release of system tray application. RC2 release of all other modules 15 Aug : Final release of all the modules (Synchronizer, Cloud Server, KConfig, KCM, System Tray Application) 22 Aug : Discussion about future direction of the project. A general public preview release and possibly a demo. 29 Aug : Discussion on general feedback and finalization road map for next 3 months *Do you have other obligations from late May to early August (school, work, vacation, etc.)? Please note that we expect the Summer of Code to be a full-time, 40-hr a week occupation. It is important to be clear and upfront about other commitments that you may have during that time.* I do not have any other commitments for summer. I intent to work for about 45 - 55 hours per week and concentrate fully on this project. Even after the GSoC, I would still like to do further development. I have big plans and great hopes for this project !! *About Me (let us know who you are!):* I have been a KDE user for more than 13 years and currently pursuing M.S. in Computer Science at Syracuse University. I have about 7 years of experience in working in software industry developing system software for Linux using C and C++. Apart from C and C++, I am also very good in Bash, Ruby and Python and my interest is in reliable, open, secure and distributed systems. Though I have been a supporter and promoter of open source software since beginning, I have never had the courage to contribute something so big to it. I believe this is the best way for me to give back, at least a part of which, what I owe to the community. *Junior job link (provide a link to a small task in KDE that you have done. It is not mandatory but will increase your chances of getting accepted considerably. If you don't know what to work on have a look at http://kde.org/jj or ask a mentor):* I have not made much contribution to open source community till now. Following are some links that shows some works that I have done in the past (some are really old and some are academic): http://sourceforge.net/projects/parser/ http://sourceforge.net/projects/e-lib/ https://github.com/jineshkj/OOD You can find more about my skill set from my LinkedIn page : http://www.linkedin.com/in/jineshjayakumar --001a11c27be0e30d9c04f4e239e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Devs,

I have submitted my final GSoC= proposal. Full proposal contents are given below. I really wish if some me= ntor could look into it and have their opinion. Thanks:

Organization:=A0KD= E

Short description:= =A0One of the problems that many users deal with on a daily basis is mainta= ining a consistent configuration on multiple desktops. Often whenever we ma= ke a configuration change in one, we have to go around on all the other sys= tems to make the same changes manually at some point in future. This projec= t aims to implement configuration synchronization to enable a seamless and = consistent experience for a KDE user across his/her KDE desktops.

Name:=A0Jinesh Jayakumar
Email Address:=A0jines= hkj@gmail.com
Freenode IRC Nick:=A0jinesh
IM Service and Username:=A0Google/jineshkj
Location (City, Country and/or Time Zone):=A0Syracuse, US. N= Y
Proposal Title:=A0Cloud support for KDE application se= ttings
=A0
Motivation for Proposal / Goal:
=A0
Technology and how it is us= ed has changed dramatically during the last 10 years. There are more people= online in the internet, using a multitude of heterogeneous devices. One of= the problems that myself and my friends face is dealing with configuring m= ultiple desktop systems in a consistent manner. I myself have two laptops a= nd a desktop (in college) with KDE installed. I believe the case is not ver= y different for most of you out there. Often whenever I make a configuratio= n change in one of these systems, I have to go around on all the other syst= ems to make the same changes manually at some point in future.
=A0
To make my point clear, let me introduce a few simple use cases. For exampl= e, when I add a new RSS feed to Akregator, I need to ensure that I manually= add the same in all my systems. Or take the case of adding a new bookmark = to rekonq or konqueror. Consider the case when I changed a keyboard shortcu= t and having to make the same changes in all other systems. It would defini= tely be a lot simple if all the configuration changes get synchronized auto= magically over internet?
=A0
Now consider the case where you plan to reinstall your OS. Or, change from = one Linux distribution to another. Or maybe you just want to use a desktop = at your friend's home for doing some leasure time coding. Wouldn't = it be a lot nicer if you could just login and synchronize your KDE session = to get the same look and feel of your own system. This project aims to prov= ide a seamless and consistent experience for any user across different KDE = installations.
=A0
=A0
Implementation Details:
=A0
Before I delve into the details of my new design, I like to explain how (mo= st) KDE applications store their configuration data. The KDE core library p= rovides all KDE applications with the KConfig (http://api.kde.o= rg/4.12-api/kdelibs-apidocs/kdecore/html/classKConfig.html) interface t= hat provides a transparent means to store application configuration data. T= he data gets stored in an application specific directory under $HOME/.kde4/= folder in an INI-type file format (by default). Although an application co= uld use custom formats (ex. XML is used by Akregator to store feed URLs) by= storing raw text, vast majority of KDE applications use the default format= .
=A0
In the new design, I intend to add few additional features to the KConfig i= nterface about which I shall explain a bit later. To begin with the new des= ign, I intend to first write a simple KDE service that starts automatically= when the user logs into their KDE session. This service takes care of sync= hronizing application configuration data present in $HOME/.kde4 directory. = The service itself would be enabled and configured by the logged in user us= ing its KCM module from systemsettings application. In order for this servi= ce to synchronize and authenticate in the cloud, user provides his/her identity.kde.org credentials.
=A0
Once the KDE service authenticates the user with identity.kde.org, it connects to the cloud service to fetch u= pdated application configuration stored in the cloud. Authentication creden= tials will be stored in KDE Wallet. The downloaded configuration is then st= ored in a local temporary store and then later provided to their respective= KDE application for further processing. This processing itself could happe= n in two ways:
=A0 =A0 1. If the application is pre= sently running in the system, it would receive a signal "configChanged= ()" from its corresponding KConfig object. This signal when captured b= y the application would receive the new KConfig object based of configurati= on data stored in the temporary store. Once the application receives this o= bject, it takes the decision as to what changes to accept and how to accept= . We would let individual app developers decide how they like to process th= e data.
=A0 =A0 2. If the application is not= running presently, it will obtain the new configuration as a temporary KCo= nfig object, the next time it starts running. It would happen the same way = as above.
Those applications that do not wish = to use signals would be presented with a polling mechanism using a new memb= er function isChanged(). If the application decides the save the new tempor= ary KConfig object as the application's, then it calls another member f= unction changeConfig(const KConfig& new_config); . As you can see here,= we have added a new signal and two member functions to the KConfig class. = The preferred way for KConfig to monitor for configuration updates from clo= ud is by watching changes to its temporary configuration directory using th= e portable KDirWatch interface.
=A0
Now, when an application modifies its configuration using KConfig, the KDE = service would receive a notification, again through KDirWatch interface. Th= e synchronization service then performs a cryptographic hashing (MD5 sum) o= f the new configuration data to check for any changes really made to it. If= the checksum differ from that present in the cloud, the new configuration = is propagated to the server. The whole process of synchronization works exa= ctly like how a version control system like Subversion works - before a cha= nge is pushed into the server, the synchronization service and the correspo= nding KDE application need to be consistent with updated configuration from= server.
=A0
While I work on the synchronization service, I would also work on having a = web service running on identity.kde.org= or similar server to provide an API, possibly REST, for the synchroniz= ation service to connect to. Although I am a fan of Ruby, I don't mind = using PHP or Python in the server side. I will also provide a simple system= tray application (similar to the one provided by Dropbox) from where we co= uld quickly control some of the functionality of the synchronization servic= e.
=A0
Since there are hundreds of applications in KDE, it's impossible to get= this feature implemented in all of them. But, to provide a proof-of-concep= t, I would like to change two applications - Konqueror/rekonq and Akregator= - to have suport for new cloud infrastructure. Konqueror would be updated = to synchronize bookmarks and Akregator for feeds. Since this is going to be= a major feature, I would rather target on KDE Framework 5. All software wr= itten, except for the cloud server, would use C++ and Qt5/KF5. Github would= be used for source control and project management. IRC and mailing lists w= ill be used for communication with other community members.
=A0
Let me also list down a few things that could be worked on in future after = the GSoC. User will be able to maintain different configuration profiles - = like home, work, etc - choose a profile to load. The service could be used = to easily backup and restore configuration data using cloud storage. A KDE = user would be also able to log in to the server's web interface and obs= erve or even control his KDE sessions from the cloud. He/she could use an e= ncryption key to encrypt all data stored in the server - KGpg could be used= for help. He/she would be able to link his KDE.= ORG account with a third-party data storage service like Dropbox, Googl= e Drive, OwnCloud, etc for storing of configuration data. He/she could poss= ibly use the KDE server more like a Bit Torrent tracker and store the data = just in his/her systems. Maybe in future, even the KDE server could be avoi= ded and use a de-centralized distributed hash tables to store the data. Pos= sibilities are infinite, usefulness is immense and time is ticking. I belie= ve KDE should introduce this feature before any other commercial or open-so= urce desktops do. This feature could very well be a unique selling point fo= r KDE.
=A0

Tentative Timeline (in weekly int= ervals until 2 weeks after the end of GSoC):
=A0
=A09 May : Project Start
16 May : Implement KCM module for KDE service configuration (esp. enable/di= sable, identity.kde.org credentials= , choose applications to sync).=A0
23 May : Implement the Synchronizer KDE service to autostart on KDE login a= nd authenticate with identity.kde.org
30 May : Implement a basic configuration storage facility in the server.
=A06 Jun : Support for using KDir= Watch to monitor for local configuration changes inside $HOME/.kde4, calcul= ating checksum and find changes.
13 Jun : Support for using KDirWatch= to monitor for configuration updates from cloud.
20 Jun : Alpha version of Synchronizer service
27 Jun : Alpha version of KConfig functionality
=A04 Jul : Alpha version of cloud server functionality
11 Jul : Modify Akregator to support synchronizatio= n
18 Jul : Modify Konqueror to support= synchronization
25 Jul : Beta version of all the above modules
=A01 Aug : Alpha version of system tray application. RC1 re= lease of all other modules
=A08 Aug : Beta release of system tr= ay application. RC2 release of all other modules
15 Aug : Final release of all the modules (Synchronizer, Cloud Server, KCon= fig, KCM, System Tray Application)
=A0
22 Aug : Discussion about f= uture direction of the project. A general public preview release and possib= ly a demo.
29 Aug : Discussion on general feedb= ack and finalization road map for next 3 months
=A0

Do you have other obligations from late May to early A= ugust (school, work, vacation, etc.)? Please note that we expect the Summer= of Code to be a full-time, 40-hr a week occupation. It is important to be = clear and upfront about other commitments that you may have during that tim= e.
=A0
I do not have any other commitments for summer. I intent to work for about = 45 - 55 hours per week and concentrate fully on this project. Even after th= e GSoC, I would still like to do further development. I have big plans and = great hopes for this project !!
=A0
=A0
About Me (let us know who you are!):

I have been a KDE use= r for more than 13 years and currently pursuing M.S. in Computer Science at= Syracuse University. I have about 7 years of experience in working in soft= ware industry developing system software for Linux using C and C++. Apart f= rom C and C++, I am also very good in Bash, Ruby and Python and my interest= is in reliable, open, secure and distributed systems. Though I have been a= supporter and promoter of open source software since beginning, I have nev= er had the courage to contribute something so big to it. I believe this is = the best way for me to give back, at least a part of which, what I owe to t= he community.
=A0
=A0
=A0
I have not made much contribution to open source community till now. Follow= ing are some links that shows some works that I have done in the past (some= are really old and some are academic):
=A0
<= div style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:b= aseline;background-color:transparent"> http://sourceforge.net/p= rojects/e-lib/
=A0
You can find more about my skill set from my LinkedIn page : http://www.linkedin.com/in/jineshj= ayakumar
=A0
--001a11c27be0e30d9c04f4e239e7-- --===============5167790820618985192== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============5167790820618985192==--