GSoC ideas I dream somebody would do…

While commenting on one of the application drafts to work on UPnP (MediaServer) support for Amarok I wondered why this proposal is mainly about support for Amarok and not the whole of KDE Platform based programs, especially as the solution is considered to be done basically as a kio-slave. To be honest, I don’t use Amarok (because I only seldomly listen to music, rather make myself some… uhm, noise), but still I would like to be able to access the content on UPnP MediaServer devices from Dragon Player, Kaffeine or Gwenview. And Okteta πŸ˜‰
Same is true for other protocols only Amarok supports. Why no DAAP (from a Firefly Media Server of course) access from Kaffeine, too? Well, there once (KDE3) was a DAAP kio-slave which, besides not being ported, seems to have been dropped due to the latest, unknown protocol version (this proprietary restrict system called iTunes should not be supported anyway). But the simple list-stat-get kio-slaves have the problem that they do not expose all of the data which is interesting to Amarok. So the Amarok hackers had to invent their own abstraction layer for the media collections you can handle in Amarok.

Collections, filtering, tagging, merging content from different sources… isn’t there some dedicated general system for that? I think there is, you guess which I mean.

So: Couldn’t someone please go and try to port the media access layer from Amarok to Akonadi/Nepomuk/Kio in a GSoC project? And if she is done also give the media access layer from Digikam the same treatment?

Why shouldn’t the envisioned Plasma Media Center also use the same engine/platform like the “plain” programs do? Currently it looks they are just going to repeat some of the work others have done before. And Picasa galleries, Youtube, Flickr, etc., would be so nice to have transparent access to that content in all KDE Platform based programs, wouldn’t it?

Just imagine showing your photos from the last Hacksprint tagged Sleep as a slide show directly from the flickr storage system in Gwenview. Or Digikam if you like. Or your own custom-made presentation program which you quickly did because you just needed to concentrate on the UI, as the elaborated storage and query system is already provided with Akonadi/Nepomuk/Kio.

Oh, just dreaming… wait, am I still sitting in front of the computer? Not laying in the bed? I should be doing that. If only because it is dreaming time…


11 thoughts on “GSoC ideas I dream somebody would do…

  1. Sure, would be nice. In fact, is that not what we are trying to do with upnp:// and it’s integration in Amarok?
    The other option would be skip the kio-slave, but then KDE as a whole won’t get anything more then one more collection (possibly redundant) in Amarok.

    Abstraction and reuse is great, in practice though (let’s say DAAP) it can get in the way of a fast and KISS implementation. I try to keep a careful balance between getting a working implementation fast and being able to generalize later.

    For some Amarok collections it makes sense: DAAP, Ampache, some services. Others are just to specific and would not make sense outside of Amarok, like the embedded MySQL.

    Is Akonadi/Nepomuk/KIO enough? Just right there is already a big problem, 3 different components needed to achieve this? Perhaps it would be simpler to extend KIO with search and a simpler way to pass additional metadata…

    • “is that not what we are trying to do with upnp:// and it’s integration in Amarok?”

      Well, no. My point is that upnp(-ms):// will just be about list-stat-get-put. But this is not sufficient for this type of content, which is why Amarok has all that added value with collections. My problem now is that it’s inside a monolithic program, not accessable to others. See the listing you gave for the storage types where “it makes sense”. Aren’t these almost all? And the local embedded MySQL also could make sense, because if somebody just wants to quickly play a file/movie from her private collection she might not want to do this with the full-featured Amarok UI (and have to start it) but use a simple UI like Dragon Player.
      Extending KIO could be another solution. But I feel Akonadi is that extension already. It is even kind of backward compatible to the KIO system (well, just akonadi:/ does not yet get you were, stuff like akonadi:?collection=0 does). Hm, still you might be right, extending KIO to get full access to the abilities of Akonadi could be the better way to go.

      I now guess the request I did in this post cannot be expected to be that much welcome by Amarok developers. After all it’s about sharing some stuff which makes Amarok stand out of the crowd. Please pardon me for that πŸ™‚ And take it as a praise because I want to have for others what you have achieved πŸ˜‰

      Just compare it to KMail and the other PIM programs: E.g. KMail now shares the content engine with Mailody. It might take away some users from KMail. Still KMail has gained a lot from this move.

  2. i’m not really sure if akonadi comes into play here at all. as a personal information management suite thing… all it would do is locally cache access to PIM data, which isn’t really in play here.

    a nepomuk collection backend for amarok was written 2 SoCs and it’s still in trunk (disabled). back the nepomuk was *way* to slow to be usable, so it never got any attention. now, with virtuoso, it might be worth polishing it up, adapting the API, and seeing if it works.

    • Just rethink what you wrote πŸ™‚ How do you define “PIM” data? Does Akonadi really care about the “PIM” attribute?

      Sure, Akonadi is currently only used for “PIM” data, but there is nothing which stops us to map other kind of data to the Akonadi data structure.

      • well, this is a question for the akonadi guys πŸ™‚

        on the akonadi home page it is defined as

        “We intend to design an extensible cross-desktop storage service for PIM data and meta data providing concurrent read, write, and query access. It will provide unique desktop wide object identification and retrieval.”

        so it seems from that at least that it’s designed for PIM data πŸ™‚ clearly it can be used for more. but remember that akonadi doesn’t store anything itself, it’s just an access layer to get to the real data wherever it may live (which in this case is also what we want of course πŸ™‚

      • I rad about aconadi backend for foto galeries. There was idea to use it for import/export kipi-plugins. Someone writed simple resource for local files as PoC. Unfortunaly I couldn’t find this post. (It was on planetkde)

  3. frinring, I agree that the scope of the project is a bit limited. I would of course love to work on overall UPnP interaction outside of the MediaServer domain right now and after GSoC. But for the proposal I’ve to stick to the bounds of the GSoC project, which I can achieve in 3 months.

    • Yes, sure, sorry, was not to offend your proposal, it would be great to see the upnp-ms:// kio-slave done.
      Just in the long run I hope for more πŸ™‚ The code of the kio-slave would for sure be reuseable, so your work will be of value in any way.

  4. So what would be the non-kio interface to a general collection concept? Perhaps a DBUS API that any given backend could implement? So UPnP, amarok, DAAP, nepomuk based collections could all be fronted by the same DBUS API and then any multimedia app could query for the data relevant to it?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s