Re: dynamic containers issue

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]