Re: [Telepathy] GSoC - Project Idea (refined)

[Guillaume Desmottes <guillaume desmottes collabora co uk>]

Le mardi 23 mars 2010 à 11:16 +0100, Salomon Sickert a écrit :
> (I'm a potential GSoC-applicant looking for feedback on a project idea.)

Hi Salomon,

> Thanks for all the feedback. After reading through all this and
> reviewing the source code of the Mathusalem Projekt¹, it becomes clear
> to me, that my idea description was not precise enough. 
> 
> (As this is a cross-post, the original post is attached)
> 
> Some notes about the project idea for SoC:
> 
>      1. Creation of a set of simple D-Bus Interfaces, which allows the
>         application developer to expose progress information about a
>         running (background) task, which the user could be caring about.
>         (e.g. Downloads, Burning, Backups, File Transfers, Printing
>         Jobs, Cloning GIT, Syncing, ...) Things the user don't care
>         about are not exposed. (e.g. updating locales-cache, rotating
>         logs, ...)

How your project will be related to Mathusalem? Will you re-use code? Or
at least some part of the D-Bus API? I think it would be worth to
discuss with Steve to not lose experience from the past.
>    
>      2. This is NOT about moving all file/io functionality in a common
>         structure (which was in my understanding the central idea of the
>         Mathusalem Project). In many cases this is not possible and also
>         requires a lot of hard work. There are simply to many different
>         protocols with specialised code. Also the approach is
>         cross-desktop and I doubt the KDE-People would like to switch to
>         an patched GIO/gvfs from their KIO. Another point is that in
>         many cases it becomes very hairy to do all the error handling.
>         In my opinion it is much easier to add a D-Bus Interface instead
>         of moving whole portions of the code. I think these are the main
>         reason, why Mathusalem didn't got integrated.
>      3. Integrating of my Interface should be fairly easy. A support
>         library should allow the application developer to get done under
>         one hour. The changes to the codebase should be minimal and
>         trivial. 
>      4. As the project aims to be ready for GNOME 3.0 (or 3.2 if the
>         deadline is not met.), I will keep the thing simple and easy to
>         migrate. In the case the project is accepted, I'm able to work
>         much of my time on the project. I hope this enables me to have
>         working base at the time for midterm evaluation and allows me
>         then to concentrate on writing integration patches for other
>         GNOME applications.

I guess you plan to write an UI displaying running tasks as well. It
would be interested to check with gnome-shell guys if that's something
they'd be interested in.

> What are the benefits?
>      1. It It is possible to create an central UI, where users can check
>         the progress of his tasks. No more ten different dialogues,
>         which clutter the workspace.  
>      2. A more unified look'n'feel.
>      3. It's cross-desktop! It doesn't matter if its GNOME, KDE or
>         whatever. It even doesn't have to draw an UI, it only hast to
>         export the Interface, the rest is done from my project. (e.g.
>         wget with D-Bus interface)
>      4. Integration with power management:
>       * When the user hits the suspend button and there are non
>         pause-able  tasks, he gets notified. All pause-able task are
>         automatically paused and resumed. 
>       * Running on battery will cause all pause-able jobs will
>         automatically paused. Running von AC will cause that are
>         resumed.
>       * ...
> 
> I hope this clarify my ideas. In the very near future a more technical
> detailed introduction can be found on my website, including a
> Proof-of-Concept.²
> 
> As always feedback is appreciated, especially from Nautilus, Epiphany
> and Empathy developers. (What are your needs, what information should be
> exposed, how much logic should stay in the application, ...)


If other GNOME projects are interested in this feature I'd be happy to
integrate in Empathy/Telepathy as well.
We'll probably use it to display file transfers. From a Telepathy pov
that could be done without modifying Empathy by implementing an Observer
[1] watching FileTransfer channel [2].


Good luck with your project,


	G.

[1]
http://telepathy.freedesktop.org/spec/org.freedesktop.Telepathy.Client.Observer.html
[2]
http://telepathy.freedesktop.org/spec/org.freedesktop.Telepathy.Channel.Type.FileTransfer.html