My GSoC Proposal: MTP Collection rewrite with emphasis on Android device support

[Philipp Schmidt]

Am Donnerstag, 25. April 2013, 17:53:16 schrieb Matěj Laitl:
> Hi all,
> this is a first draft of my GSoC project proposal. I'd be more than happy to
> see your comments, remarks, whether something is unclear or maybe where I'm
> too verbose.

Hi,

as the Maintainer of KIO-MTP I have some thoughts. And no, I think its best 
not to use kio-mtp as a Backend for the reasons you have stated. There are 
however some things that you may not be aware of (I do not know if you are 
reading the libmtp mailinglist). I will only comment on the (lib)mtp specific 
parts as I do not have deeper knowlegde of the inner workings of Amarok.

First off, using LIBMTP. While it currently is the best option to access 
Devices directly it would be very good to design the Access in a way that 
allows to also use a DBus Interface [1]. There are some Ideas on the ML about 
that, sadly nothing specific yet. Basically Philip Langdale, the gvfs-mtp 
developer, some of the LIBMTP devs and myself wanted to create something like 
the "Windows" experience for MTP, where a daemon accesses the devices 
centrally and provides access via DBus. This would 

 a) simplyfy simultaneous access from multiple applications as accessing a 
device from a different application WILL force the previous connection to 
close which can result for example in the following:
  - you are copying some photos using kio-mtp and try to access your music: 
boom, file transfer gone. 
  - The mtp stack of most samsung devices will freeze: You will need to unplug 
and replug the device as they do not handle this situation at all. Yes that is 
non-conforming behaviour but Samsung devices are the vast majority out there, 
so even completely valid from a developers POV one of the reasons I won't 
label the current kio-mtp 1.0.

So that will solve quite a lot of issues.

 b) enable us to develop access libraries using Qt or GTK or whatever that 
encapsulate the DBus calls and provide an API consistent with KDE, Gnome or 
whatever. E.g. no more low level C calls in Qt4.

I will try to get some thoughts for the interface specifications under way 
soon so your input in creating the part of the interface that provides access 
for media players would be greatly appreciated. While such a daemon will 
probably not be ready in time for GSOC creating the Backend in such a way that 
adding support for synchronous or preferably asynchronous DBus access would be 
a very good thing.

While it is safe to say that the low level interface will always be there, for 
one for backwards compatibility but also console applications, but for gui 
applications DBus is the way to go.

Cheers,
Philipp Schmidt


[1] http://sourceforge.net/mailarchive/forum.php?thread_name=CAKnu2Mqj-MTObET5V%3DOHN5cOaqrkzWB7QaKK-HPBn%2BtA0dngwg%40mail.gmail.com&forum_name=libmtp-discuss