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
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
