My GSoC Proposal: MTP Collection rewrite with emphasis on Android device support (for Amarok)

[Matěj Laitl]

On 25. 4. 2013 Philipp Schmidt wrote:
> Matěj Laitl wrote:
> > 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.
> > 
> > Link: https://mail.kde.org/pipermail/amarok-devel/2013-April/012000.html
> 
> Hi,

Hi Philipp,
first of all, HUGE thanks for letting me know all of this, this is immensely 
useful for my proposal and (hopefully) for future Amarok MTP support.

> 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've subscribed just now (I should have done it earlier), CCing the list as 
this may be interesting to other libmtp people.

> 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.

I'm all in! And I think I could help (at least by checking that the DBus API 
would be useful for Amarok use-case, but hopefully more by actually doing some 
of the work).

> 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.

I absolutely agree. Even before I knew about this, the plan was to have *all* 
LIBMTP_*() calls (or rather groups with a handful of libmtp calls) wrapped in 
ThreadWeaver::Jobs, for technical reasons (some libmtp calls may block for 
some time -> need to have them threaded -> libmtp doesn't say anything about 
thread-safety AFAICS -> need to serialize access to it (per device) -> all 
libmtp calls may then block on lock acquisition -> all libmtp calls must be 
threaded).

So, by coincidence, this should allow to convert the threading jobs to 
(wrappers around a handful of) QDbusPendingReplies, just changing the "type of 
asynchronicity" (and getting rid of locking). And now that I know the plan, I 
can intentionally make it easy to do so. In future, some bits may even be 
factored out into a hypothetical "Qt MTP dbus client library". What do you 
think?

I will update my proposal to reflect this exciting development and also think 
of how I may involve.

> 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.

Agreed.

[oh, now your "Ideas, proposed rough Roadmap and Requirements for a DBus MTP 
daemon" mail arrived, nice timing ;) ]

Thanks again,
		Matěj