HaraldSitter

Contact information

• Your Name: Harald Sitter

• Email Address: apachelogger@ubuntu.com

• IRC nickname: apachelogger
• Launchpad ID: apachelogger
• Skype username: apachelogger

• Webpage/blog: http://apachelog.wordpress.com

• College-University: Graz University of Technology
• Major: Software Development and Business Management

Project

• Project Name: Ubuntu One for KDE
• Project Description:
  • The target of this project is bringing Ubuntu One awesomeness to the KDE workspace. Combining the very best online services suite with the very best free desktop technologies. Ever since the Ubuntu One file storage and syncing service was announced, there was demand for a KDE client, so that it better integrates into the existing desktop environment. Meanwhile Ubuntu One grew beyond file syncing and now offers synchronization of various data types. Now it is time that Ubuntu One gets hooked up with KDE technology, since the combination of both has potential for pure awesome. This project should at the very least produce a sensible implementation of the very basics that are necessary, so that applications built with KDE technology can easily interact with the Ubuntu One services. Ultimately will it enable the user to sync every content that is stored in KDE's PIM storage solution Akonadi, via Ubuntu One, and provide the means to configure the Ubuntu One service to their needs.
• If you would be willing and able to do other projects instead, which ones?

  • Any relating to KDE or Qt really In particular Kubuntu File Sharing or Package Manage Improvements though.

• Why did you like this idea?
  • I do own 3 computers myself, keeping data in sync across all of them is actually impossible. If you add my phone into that mix, I have 4 devices, of which some do not even run the same operating system/desktop environment, I would have to to sync data across. Quite the nightmare. At Kubuntu, I am already contributor there, we thought about making bookmarks sync across devices, but didn't get to a sensible solution as of yet. Ubuntu One would solve this problem. Especially if we can get it integrated with Akonadi, the KDE data storage solution for PIM data (and bookmarks), then using Ubuntu One to sync data across various devices will be a matter of authenticating the device. For this very reason and my personal interest on this, I was poking a bit around last year and came up with a tech preview, that does nothing more but tell the user what is currently happening. Unfortunately I had to drop development shortly after that because other things came up. Now I am thinking, instead of spending the summer doing javascripting for a website (or something similar) I cloud spend the time on bringing Ubuntu One goodness to the KDE workspace.
• Please describe a tentative project architecture or an approach to it:

  • 

  • First and foremost a connection with the Ubuntu One SyncDaemon must be created. SyncDaemon is essentially the heart of Ubuntu One, and is responsible for interaction with the cloud. Currently I think that the best approach to this might be to create a library that maps the DBus interfaces of SyncDaemon to functions we can use in the actual implementations, also, if necessary, this library would contain convenience wrappers. Please note however, that the most work of this library would really be demarshalling the content obtained from the SyncDaemon so that it can easily be used in the implementations.

    • At this point an alternate approach is also possible, which is eventually the same, but instead of creating a library, that connects to SyncDaemon for each call, and using it to connect to signals SyncDaemon would emit, a KDED module would be implemented. A KDED module is a smaller helper app that runs in the background (and does thus not have a visible user interface). This module would upon start connect to the SyncDaemon (i.e. establish a persistent connection), the implementations would then talk to the KDED module (via DBus) and the module to SyncDaemon (also via DBus). Other than that this approach is not much different from a library.

    • Whether to use a KDED module or a library is yet to be decided. Since KDE is working on their ownCloud (their own cloud service implementation) it would be very wise to first get in touch with the ownCloud authors and maybe find a solution that can be used for both Ubuntu One and ownCloud, thus sharing maintenance effort and providing an overall better experience to the user.
  • Secondly auth handling needs to be implemented, this will probably a straight forward port of the GNOME auth-handling, just that our dialogs will be using KDE and that the auth token is stored in KWallet. Just to quickly explain how authentication is done: the ubuntuone-launcher looks for an authentication service via DBus (in our case hopefully starting the KDE one ;)), the handler will then try to obtain an oauth token, either form a previous authentication that stored the token in KWallet, or by invoking a browser and directing it to the appropriate site so that the user can give authentication, which then gets stored in KWallet.

  • Once the interaction with SyncDaemon is setup there are two options. Either stay with the backends for a bit longer, or start implementing frontend integration based on information that can be obtained from SyncDaemon (namely configuration, status notification and dolphin integration). I would suggest that this decision gets done when the time has come, so that the more important task can be selected depending on how much time is left until end of GSoC.

  • In the area of frontend development we can at this point create:

    • Ubuntu One StatusNotifier (fancy new tray icon) to inform the user about status (changes) regarding the Ubuntu One SyncDaemon.

      • This is straight forward and mostly implemented in the tech preview implementation I did some time ago.

    • A Configuration interface to manipulate settings of the Ubuntu One SyncDaemon.

      • This is also very straight forward, it is however appropriate that this probably should be implemented as a KCM (a KDE configuration module), so that it can easily get embedded in both, the systemsettings application AND any other application that might want to allow the user to change settings (Amarok comes to mind, once it grows Ubuntu One Music Store support).
    • Dolphin integration
      • Dolphin integration refers to providing status information on Ubuntu One tracked content (files/directories) directly inside KDE's file browser. This is a very delicate topic that should be discussed with the Dolphin developers and the ownCloud developers so that we end up with a perfect solution that can be used for many years and ultimately is shared across file-sync services like Ubuntu One and ownCloud. Basically we have 2 possible approaches:
        1. Implement this as a KIO slave. This has the advantage that status information about the content is not only being visible in Dolphin but any other file browsing dialog. I imagine that this could be useful when you want to save a file and see that it is currently being sycned, so smart user that you are, you will wait 2 seconds to avoid possible conflicts etc.. It however raises the question as to how exactly one would switch from the standard file browsing slave to the Ubuntu One one, especially if Ubuntu One syncs more than one location.

        2. Implement it in Dolphin's view part, as seen in KDE 4.4 with their SVN implementation. The advantage here is clearly that we could help the Dolphin Developers establish a plugin API for such kind of views, which then could be used for other implements (e.g. bazaar plugin). This however also bares the problem of how to detect that a folder is watched by Ubuntu One (possibly a cookie file could be placed in such directories?). Also, this implementation would almost certainly require the interaction with SyncDaemon to be done via a KDED module, so if the KDED module is not available, the view part would just turn of it's "Ubuntu One plugin".

  • By further backend development I referred to creating (or rather improving) an Akonadi resource agent. Akonadi is KDE 4's central storage unit for PIM data and a resource agent for Akonadi is like a storage access plugin. In order to make Akonadi able to interact with Ubuntu One data, we need a resource agent for DesktopCouch DB, which is the brain of Ubuntu One. Basically all entities of Ubuntu One are stored in a DesktopCouch DB, the SyncDaemon does nothing more but link the local DesktopCouch DB with the cloud. So being able to read and store data in the database is key to giving KDE software 100% exposure to Ubuntu One. Fortunately enough there are already parts of such a Akonadi resource available in KDE's SVN, so we could build up on this and maybe get to results pretty quickly.

    • When the basic DesktopCouch DB resource is done, we can dive into making Akonadi read and write data from/to the Ubuntu One database, which essentially means that we can sync about any PIM data via Ubuntu One.

    • To be more precise: making Akonadi interact with the Ubuntu One Desktop Couch DB means that any, let me repeat --> ANY <--, application that uses Akonadi for storing its data can then make use of Ubuntu One without additional code on this part!

  • Should still be time, we could look into implementing Ubuntu One Music Store support into Amarok. I do think it is unlikely that we get that far though. Without looking at the Amarok API I can not say a lot about the specifics here though. What I know thus far is that the Ubuntu One music store is only accessible via a web page, which is a bit of a problem, since Amarok would feature a very awesome API that would allow extremely integrated solutions for music stores, so if we could get the 3rd party content providers to consider this, the implementation could be a lot more awesome. Until then I imagine we could either patch an addtional entry in Amarok's media sources list (that is the tab where you find local music, internet, playlists ...) that shows a QWebView of the web page. Otherwise, if possible we might be able to do this via a plugin in the Internet area (I am not sure if we can opt for a QWebView then).
• Give us details about the milestones for this project
  1. Get in touch with ownCloud developers and KDE developers, especially with former a common plan of ideas and requirements should be outlined
  2. Create a precise plan for implementation, based on discussion from the previous milestone

  3. Implement either a library or a KDED module for communication with SyncDaemon

  4. Implement KDE auth handling (until this is done we will just use GNOME's implementation)

  5. Implement SyncDaemon fontends (configuration + status notification)

  6. Implement Dolphin integration based on results from on-going discussion with upstream and similar implementation authors (i.e. ownCloud)
  7. Ensure everything is nice and shiny (we can end the project here and call it a success)

  8. Implement DesktopCouch Akonadi resource

  9. Make Akonadi talk to the Ubuntu One database
  10. Ensure everything is nice and shiny (we can end the project here and call it even more a success)
  11. Implement Music Store support in Amarok
  12. Ensure also that this is nice and shiny (we really should end the project here and call it awesome overkill)
• Why will your proposal benefit Ubuntu?
  • By providing Ubuntu One not only to GNOME users, but also KDE SC users, you open up a whole new market of possible customers to the Ubuntu One service, eventually allowing Canonical to make more money and in consequence spend more money (on Ubuntu). What is probably even more important though, is that you make a lot users happy. Users like me, who happen to have various devices that ought to share some set of data, but currently can't in a decent way. And despite what people say, one doesn't use a distribution for its stability (usually), but for it's uniqueness, Ubuntu One in KDE would make Ubuntu quite unique, especially considering the very high quality that Ubuntu One is.

Open Source

• Please describe any previous Open Source development experience
  • Amarok release manager and promoter

    • Back in the days a couple of Amarok peers and I founded the Amarok marketing team, ever since Amarok has cool release publications and strong presence at fairs and conferences

    • As release manager I was mostly responsible for getting releases going, setting the roadmap and the like
    • In consequence I also created a script framework (in Ruby) used for creating source tarballs, it is now used for Amarok, Digikam, KIPI and Choqok releases.
  • KDE Contributor
    • From time to time one can find me at KDE booths at fairs and conferences (next time in April 2010 @ Grazer Linuxtage ;))
    • Minor bug fixes in C++

    • Created the Firefox Oxygen theme, which is now mostly replaced by theme mapping via QtCurve-GTK+ (which I personally find a much saner approach to desktop integration)

  • Kubuntu Developer
    • I am Ubuntu Core Developer and mostly get down and dirty with large scale software deployments, bug triage/fixing and keeping the l10n architectures up with latest and greatest KDE trends
    • Occasionally I also do application development, for example:
      • kubuntu-debug-installer (C++)
      • kubuntu-firefox-installer (Ruby, meanwhile rewritten in C++)
      • apturl-kde (Python)

  • I have also released various small scripts and tools in Bash and Ruby (for example http://people.ubuntu.com/~apachelogger/scripts/deb-sourcecheck)

  • On a releated note: I also created a tech preview of an Ubuntu One client implementation for KDE http://apachelog.wordpress.com/2009/11/25/ubuntu-one-kde-tech-preview it is however really just a tech preview and far away from anything useful. Unfortunately I had to let go of development because I had to focus on other things.

• Why are you interested in Open Source?
  • May I say that this is indeed a very difficult question. I suppose it's really a lot of things, small and big alike. Something I like a lot is not so much about open source itself, but the FLOSS movement. The (cultural) diversity of communities is just awesome. I personally enjoy it a lot to work with people from across the world, simply because the attitudes to certain things are different, or the personal believes for that matter, and this makes decisions mostly much saner than if you just make them in a team of french engineers for example. It also happens to be that a lot of non-developers contribute to FLOSS projects and take part in the decision making, which is a wonderful thing, because it helps with maintaining sane engineering and keeping the "regular folks" in mind. Now about the technical interests in open source. Open source's most important treat to me is the free share of knowledge it enables. Even open source software of which you cannot use the code as you choose, offers knowledge. So maybe you want to solve problem X and have a somewhat working but slow solution to it, you know that the related problems Y and Z were already solved in some open source software, so you take a look at that solution and suddenly find yourself inspired by a completely different approach, ultimately leading to a wonderful solution of problem X. This is but one thing I like a lot about open source software. Another (which is again more related to FLOSS) is, that you do not need to reinvent the wheel to archive cool things, you can mostly reuse solutions of others, save time, money and maybe get the job done better than if you had done everything yourself (simply because the appropriate solutions were implemented by specialists in their field).

Availability

• How long will the project take? When can you begin?
  • Time estimates:

    • The first part (SyncDaemon implementations) could be done in about 4 weeks, depending on which implementation options from above get selected and how long it takes to reach a decision there.

    • The second part (Akondi<->DesktopCouch) would probably also require at least 3 weeks, depending on how far along the code in KDE's SVN really is.

    • Part three (Music Store) is entirely depending on how dynamic the 3rd party provider really is and whether one can make use of QWebView via Amarok scripts. But if there are no particular obstacles it should be doable in 1 week minimum.

  • Can begin once Kubuntu 10.04 is released

• How much time do you expect to dedicate to this project? (weekly)
  • I suppose between 30 and 40 hours per week.
• Where will you based during the summer?
  • Graz, Austria
• Do you have any commitments for the summer? (holidays/work/summer courses)
  • Nope.
• Please designate a back up student (in case you need to withdraw your application)
  • Jonathan Thomas would be perfectly capable and willing to do this.

Other

• Have you ever participated in a previous GSoC? (describe your project)
  • No.
• Have you applied for any other 2010 Summer of Code projects? If yes, which ones?
  • No, most others didn't strive me as interesting, and others I have in mind would require most of the time just to outline a good code design (let alone UI).
• Why did you apply for the Google Summer of Code ?
  • I do consider GSoC a viable chance to finish what I have started some time ago with poking around in the Ubuntu One source and implementing a quick hack tech preview. Since I currently do not have any work commitments in summer, I figured it would be just as well to finally implement Ubuntu One for KDE to improve my programming skills and at the same time solve one of my own biggest problems (keeping my devices in sync).
• Why did you choose Ubuntu as a mentoring organisation?

  • Clearly because the Ubuntu project rocks :D. Also since I am Kubuntu user and promoter, my friends and I directly benefit from improvements (as noted above, especially an Ubuntu One integration for KDE would make my life a lot easier

• Why do you want to participate and why should Ubuntu choose you?
  • I am already "hooked up" in the project, know the work flows and whom to ask when something specific is needed. So I do not need to spend a lot of time on getting into the natrual bureaucracy. I do already have experience with the codebase and Ubuntu One's design from my earlier looking into creating KDE integration. I do have a very clear idea of where the journey is going and am eager to practice my C++ and KDE. Additionally I have a strong personal interest in getting this project done, so that I can finally have synchronized systems.