Re: adding playlist support to grilo

["Juan A. Suarez Romero" <jasuarez igalia com>]

On Thu, 2013-02-07 at 00:22 +0100, Mateu Batle wrote:
> Hi all,
> 
> It would be great to get some feedback about implementing a new feature
> for playlist support in Grilo.
> 

Thanks for coming with that feature.

I'd like to mention that Mateu and I were talking in IRC, so mostly we
agreed with what we think it is the best approach.

> Let me explain myself with an example: imagine browsing the filesystem
> and a playlist is found (currently it is shown as GrlMediaAudio in case
> it is shown at all). With this feature, the playlist would be mapped to
> a GrlMediaBox while browsing (so a like a virtual directory), and the
> entries of the playlist would be shown as GrlMedia objects inside the
> GrlMediaBox. In this way, applications can browse easily into existing
> playlists. Probably we want this feature as optional, so it can be
> enabled / disabled for the plugins or sources that make sense.
> 
> There are several ways to add this functionality into Grilo:
> 
> (a) Hardcode the feature into an existing plugin. Not that good, since
> several plugins could need this, and it would not be possible to reuse
> easily.
> 
> (b) Implement the feature as a new plugin, and add some glue code into
> each plugin that wants to use it. So it would be a plugin that is used
> by other plugins (instead of applications), which is not usual in the
> grilo design. Grilo is more designed to make plugins collaborate without
> knowing each other. This could be done through test_media_from_uri &
> media_from_uri API for example, or even the query API.
> 

I think this choice is the least recommendable, because it would make
its use a bit complex.

Main reason is that plugins collaborate among them to provide each piece
of missed information. But they do not change neither the content nor
the type of media.

So if a plugin provides a playlist as a GrlMediaAudio, no other source
will change it to another type, like GrlMediaBox.

Using media_from_uri() wouldn't help at all, because it would require
the application to explicity ask that playlist-source to convert the URI
into a GrlMediaBox.

> (c) Implement the feature as a library (similar to the way done with
> GrlNet), which can be reused from other plugins or applications. So we
> can provide the best API for this feature and not be limited by the
> grilo plugin API as in (b).
> 

This option can be combined with (a), so we could provide this utility,
and any source that want to expose the playlists as a GrlMediaBox could
use it to peform that task.

Moreover, even applications could use it in case the want to expand
playlists that come for sources that do not expand them.

> After some short discussion about these options, (c) is the one I like most.
> 
> The idea is to use totem playlist parser library, which seems to parse
> most popular formats and it is part of the gnome family, apart of
> already being used in grilo plugins (optical media plugin).
> 
> Another use case or implementation of the library could be using the
> tracker database, which internally uses totem playlist parsing library.
> However, currently tracker or grilo tracker plugin do not do this
> mapping to virtual directories. Depending on our environment, we might
> have already this information available in the tracker store, so it
> could be possible to get it from there. What is not so clear is if get
> it from tracker is really more efficient than parse a file with totem
> library. I guess we could find some case where tracker store is more
> eficient, maybe with playlist with lots of entries or when we require
> the count of items in the playlist.
> 

I would use totem-pl-parser and forget about Tracker. Main reason
(besides Tracker not being in all platforms), is that Tracker won't
expand playlists that come from online sources, while your library
could, using totem-pl-parser.

> I haven't thought much on the API yet, but the goal is to make as simple
> as possible the glue code to be written in a plugin in order to
> implement the playlist support feature.
> 

One way could be using a similar approach as search() or browse(); that
is, invoking something like grl_pls_expand(GrlMedia *playlist,
GrlSourceResultCb callback, gpointer userdata) and receive the results
as callbacks.

This would make easier to integrate it with browse() and search():

if (element is a box) {
   grl_source_browse(element);
} else if (element is audio) {
   if (element.mime is playlist)
      grl_pls_expand(element);
   } else {
      play (element);
   }
}

A better approach could include also a list of desired keys, and
GrlOperationOptions. So user could ask which keys she wants, and the
function could use grl_source_resolve() to add those keys to each of the
items.

In any case, feel free to propose any API either here or in the IRC.

Cheers.


	J.A.