Re: media_from_site API

[Iago Toral Quiroga <itoral igalia com>]

El vie, 03-12-2010 a las 13:53 +0100, Juan A. Suarez Romero escribió:
> On Fri, 2010-12-03 at 12:22 +0000, Iago Toral wrote:
> >  The case of the URL conversion is an obvious use case that makes
> > sense. 
> >  Do you have any examples where other data could be used and the url
> > is 
> >  not available? If you find good use cases for that I would be willing
> > to 
> >  go for this version, otherwise, I would postpone the idea until we
> > have 
> >  specific use cases that we think are reasonable and I would keep it 
> >  simple for now.
> 
> Well, I was thinking about services that can unambigously identify a
> media besides the ID or the webpage that refers to the media. Right now,
> only youtube comes to my mind, about the GRL_METADATA_KEY_EXTERNAL_URL
> or GRL_METADATA_KEY_EXTERNAL_PLAYER, which could be used to get the
> media from their values.
> 
> Is this a good use case? Well, depends on the application. Bastian well
> explained a good use case for the MEDIA key. As I didn't develop a Grilo
> based application, I can't tell you about other keys.

Well, that was my point :)

> But a use case that comes to my mind (not sure if it can be done with
> the current API) is a way to retrieve a GrlMedia from the URI itself.
> Sometimes you want to create a GrlMedia for a specific url, like
> file:///home/user/mymusic.mp3. This could be done with the proposed API,
> using the URL key and if plugin is willing to do it.

That can be done with the API I implemented already, the idea is that
you get a GrlMedia representation from a URI representing the media. We
could rename it media_from_uri instead of media_from_site if you like
that more.

> 
> > 
> >  Also, there is another issue, for the case of the url, it is not
> > enough 
> >  to know if the source supports conversion from the url, you also need
> > to 
> >  know if the source supports that url in particular (hence that 
> >  test_media_from_site), probably this is specific for the url case 
> >  because with other that this check would probably not make sense, so 
> >  even in the situation of wanting a more generic approach, it could
> > still 
> >  make sense to have the media_from_site API as a separate option.
> 
> Yeah, of course. In fact, the algorithm would be quite similar to yours.
> For all the plugins that support inverse resolution from MEDIA, it will
> try each one until finding the first that is able to resolve that
> specific URL. Plugins could just send a NULL media if they can't resolve
> in the callback, or returning 0 in the function to tell they can't
> resolve it (synchronous way). Don't have a preference here.
> 
> Plugins would implement something like test_media_from_site(), as in
> your proposal.

The thing is that this "test" does not make sense for all the other
cases. In the case of the URI I can check that in the youtube plugin I
won't support URIs that don't belong to www.youtube.com for example, and
then avoid any kind of network I/O, but if I know other keys like song
title or artist name, then that won't help me at all, I would have to
query the backend to know if they can match a specific song/video and I
won't save any work.

Also, I was wondering, in the case we want to do a really generic API
should we not support thinkgs like this?:

Artist: X, Album: Y

Which is a 1:N relation (unlike the URI, which is alwaya 1:1). The
result would not be one media, but a collection of them, in which case
the behaviour would be more like that of browse/search instead of
metadata. If we are really interested in having a generic API for
reverse resolution we should do this instead.

For all these reasons I still feel like having specific API to handle
the URI case makes sense: it has a very clear use case and would define
a very simple API to explot it. Then, we could have a more generic API
to handle all kind of reversals from any combination of metadata the
plugin developer is willing to provide that can do any 1:N combination.

Iago