GSoC Proposal : Cloud support for KDE application settings

[Jinesh K J]

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 at 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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20140318/6808f918/attachment-0001.html>