Re: dynamic containers issue

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

Hi,

On Tue, May 18, 2010 at 11:08 AM, Juan A. Suarez Romero
<jasuarez igalia com> wrote:
> 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.

 Errr.. the "place" in "in the first place"  doesn't mean the
placement in hierarchy. :)

http://www.yourdictionary.com/idioms/in-the-first-place

  I meant to say was that you should *try* your level best to avoid
such extremely huge containers by:

1. Not defining too generic containers like "All videos".

2. Create deeper hierarchy. e.g instead of:

All Artists
   |
   |-----> Bob Dylan
   |                  |---> Song1
   |                  |---> Song2
   |-----> Michael Jackson
                     |---> Song3
                     |---> Song4

you do:

All Artists
  |
  |---> A
  |---> B
  |        |
  |        |----> Bob Dylan
  |                     |--> Album1
  |                               |---> Song1
  |                               |---> Song2
  |....
  | --> M
           |----> Michael Jackson
                       |--> Album2
                                  |---> Song1
                                  |---> Song2

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

  Yeah, just that one is even slower than the other and our main
problem is efficiency here.

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

  And what exactly is that? When I was working on MAFW, we never had
any such sources so I don't recall bumping into these issues.

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

   Not really, you can have as many children in a container you want
and as I (& Lennart) told you many times in the past that the static
content issue you talked of is not really a problem of the spec but
dbus-glib limitation. All it requires from you is:

1. Know the number of children (no need to know how many of them are
containers and how many items anymore).

2. Notify any changes in the container.

   If some source doesn't give your means to implement this easily,
its really a bug in the APIs provided by those sources. Since you have
no way to making them change their APIs (at least not anytime soon),
the solution is to simulate the required behavior by some clever
tricks in your middle-ware, like the one I mentioned in the previous
emails.

> In the above example, I think providers should be able to notify
> "unknown" ItemCount/ContainerCount values.

  How exactly does that improve anything for the example above?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124