Re: media_from_site API

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

On Fri, 2010-12-10 at 11:58 +0100, Iago Toral Quiroga wrote:
> The problem with that is that the work-flow would be like this:
> 
> grl_multiple_reverse_metadata (...)
>   => If returns TRUE then I have to check the result in the callback
>   => if returns FALSE then there is no callback involved
> 
> It is just less convenient because depending on the result of the
> function you have to expect a callback to be invoked or not. Or we
> could
> make it use the callback also for the FALSE case, but that would not
> be
> convenient at all if you just want to look for the appropriate plugin
> for a certain URI (just select the right plugin).


Yes, I already mentioned it.

My opinion:


                      inverse_metadata()              youtube_inverse()
[USER APPLICATION] <----------------------> [CORE]
<--------------------> [YOUTUBE PLUGIN]


The public api inverse_metadata() would always return the result in the
callback (NULL if none of the plugins would be able to resolve the
data).


The plugin implemented youtube_inverse() would return TRUE or FALSE if
it's able to resolve the question. If so, the resolved value would be
returned in a callback.

An alternative to the latest case is splitting the function so we have a
youtube_is_able_to_inverse(), which just would return TRUE or FALSE, and
a youtube_inverse() which inversely gets metadata and send result as
callback.

A third alternative could be that youtube_inverse() just returns the
media ID, or NULL if it isn't able to resolve it. With this ID, the core
can build a GrlMedia with the ID, the source and the key-value which was
resolved. If user was asking for more keys, core can then use the
standard get_metadata() to fill the requested keys.


	J.A.