Re: media_from_site API
- From: "Juan A. Suarez Romero" <jasuarez igalia com>
- To: grilo-list gnome org
- Subject: Re: media_from_site API
- Date: Fri, 03 Dec 2010 13:53:37 +0100
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.
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.
>
> 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.
J.A.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]