Re: media_from_site API
- From: Iago Toral Quiroga <itoral igalia com>
- To: grilo-list gnome org
- Subject: Re: media_from_site API
- Date: Fri, 10 Dec 2010 10:33:55 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]