Re: dynamic containers issue

["Zeeshan Ali (Khattak)" <zeenix gmail com>]

Hi,

On Fri, May 14, 2010 at 8:39 PM, Juan A. Suarez Romero
<jasuarez igalia com> wrote:
> On Fri, 2010-05-14 at 19:23 +0300, Zeeshan Ali (Khattak) wrote:
>> Regarding the performance problem you mentioned, I suggest you bite
>> the bullet and browse the whole container to count the number of
>> children since user will have no way of knowing that and once she
>> realized that we are only showing part of the complete listing, she
>> will get really annoyed. In order to hide this issue from apps/user,
>> what you could do is to report 0 children in such containers when a
>> client asks for this property, start browsing asynchronously the
>> container(s) and emit an updated signal for the container once you
>> know the number of children.
>
> 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.

2. If you don't do this, Rygel will have to do this and you can
imagine that will slow this down even further.

> 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.

> The point here is that I need to take care of all kind of plugins. And
> Youtube is a good example of these problems.
>
> 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.

> Anyway, still I can use your proposal to fixing other problem: as the
> ItemCount/ContainerCount/Items/Containers is computing everytime client
> asks for them, if limit is too high could be that client receives a dbus
> timeout. One way to fix it is, as you say, whenever the user ask for
> them just returning 0, browsing them in background, caching the result,
> and then sending Updated signal.
>
> But even in this case, we need to set some kind of limit; otherwise,
> either it can take an eternity to get the results, or worst, being
> banned by provider for abusing :).
>
> And I don't see any problem with the limit: user is (or should be) aware
> that rygel-grilo is running with a limit, which even he can change if he
> wants: the higher the limit, the slower will be (and more
> resource-consuming).

  Yeah I agree completely here: The combination of the solution I
proposed combined with limiting the results (if really needed) is the
only way to solve this.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124