Re: dynamic containers issue

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.

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

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.

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


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