Re: dynamic containers issue
- From: "Juan A. Suarez Romero" <jasuarez igalia com>
- To: "Zeeshan Ali (Khattak)" <zeenix gmail com>
- Cc: grilo-list gnome org
- Subject: Re: dynamic containers issue
- Date: Tue, 18 May 2010 10:08:39 +0200
On Tue, 2010-05-18 at 02:03 +0300, Zeeshan Ali (Khattak) wrote:
> > Yeah, I can send just 0, but browsing in background to get all elements
> > is not is not feasible. Let's think in Youtube, for instance. Do you
> > think that it is feasible to browse *all* available videos just to get
> > the ChildCount/ItemCount/ContainerCount. I don't think so.
>
> 1. No, I wouldn't even imagine you having containers with all videos
> in the first place. If you have such containers, you need to redefine
> your hierarchy.
It doesn't need to be in first place: I can have "all videos" or "all
artists" just in a 2nd or 3rd place.
>
> 2. If you don't do this, Rygel will have to do this and you can
> imagine that will slow this down even further.
I think Rygel will do it as I'm doing it in rygel-grilo; problem is
moved from one place to another, but it's still there.
> > Moreover, when you finish the browse, how can you guarantee that the
> > data is actually up-to-date? Youtube is not telling if it "changed".
>
> Thats the problem I mentioned in my first email: How does a client
> *reliably* incrementally browse a container when the container's
> children can just go away and there is no notification of that? You
> asked me for an example, now you provided one yourself. :) BTW, the
> spec always (v1 and v2) required containers to notify of changes.
How a client browse Youtube service, which doesn't have a "updated"
signal? I think the same applies here.
How a client browsed with MAFW framework? The same applies here.
> > Still, I don't see why applications need to use that keys, actually. I
> > think that ListChildren should be what they need to use.
>
> You are assuming that client is always browsing each and every
> container it shows interest in, which is not the case. Suppose client
> only browsed the root container which has 3 child containers. In this
> request the client asked for the number of children for any containers
> in the result. Now we need to provide this prop for all the child
> containers even though the client has not yet shown any interest in
> the children of these containers. Actually this is a very good way
> for clients to know whether or not they need to browse a container or
> not.
>
Well, as I already told you, I think the spec is very focused on
providers with a rather limited and static content, not for providers
like Youtube or other web service.
In the above example, I think providers should be able to notify
"unknown" ItemCount/ContainerCount values.
J.A.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]