On Wed, 2014-01-22 at 14:07 +0100, Bastien Nocera wrote:
> > One solution could be sending also the container where the element
> > belongs. So application knows if the element is of interest or not. And
> > on top of this, for those very lazy applications, they could choose to
> > just re-launch a browse of the container instead of adding the added
> > element.
>
> Lazy applications, not really. With the current signals we wouldn't know
> where to add newly added items even if we wanted to. Sending 2 change
> notifications saying "this is the item we added, this is the container
> that changed" is really impossible to implement because you'd be sending
> 2 separate signals (the change type is different).
>
> So the way to fix this properly is adding a new notification function,
> and adding a new signal.
>
I meant changing the notification signal and notification funciton to
include the parent container.
Of course, to avoid breaking the API, instead of changing the signal and
notification function we would add new ones and deprecated the olders.
> > > > I think if you want to do lookups only using one source, you would need
> > > > to do it by hand, calling resolve().
> > >
> > > grl_source_resolve() needs to be called by hand in all cases, doesn't
> >
> >
> > Yes, grl_source_resolve() needs to be called, unless you want to allow
> > to do it in the browse itself.
>
> If I use that as the browse flags:
> GRL_RESOLVE_FAST_ONLY | GRL_RESOLVE_IDLE_RELAY | GRL_RESOLVE_FULL
>
> tmdb still looks up metadata about the media even though it is slow.
> That doesn't sound like the right behaviour to me.
Yes, TMDb looks up for the data because you specify GRL_RESOLVE_FULL,
which means using all the available plugins. Note that
GRL_RESOLVE_FAST_ONLY doesn't avoid using TMDb, because the flag applied
in each source; that is, from TMDb point of view, maybe all the keys are
'fast' because it requires just one request to the service, except one
or two keys that are marked as non-fast because if you ask for them,
they would require more than one request to TMDb. So using
GRL_RESOLVE_FAST_ONLY | GRL_RESOLVE_FULL would avoid asking those two
keys, but not the others.
>
> > My point is that if you want to call only local-metadata, you need to
> > invoke resolve() over local-metadata. But if you want to use all the
> > plugins, you could use directly the same source you used to browse, and
> > let Grilo to choose which plugins should invoke to satisfy the
> > requirement. You could set up priorities in the sources so, for
> > instance, local-metadata is used before TMDBb.
>
> Right, but that means doing a lookup on tmdb for a thumbnail if the
> local file doesn't have a generated one.
>
Yes. At this moment, we do not have a way of selecting the specific
sources involved in the requests.
J.A.
_______________________________________________
grilo-list mailing list
grilo-list@gnome.org
https://mail.gnome.org/mailman/listinfo/grilo-list
