After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 661988 - Correct handling of containers w/ unknown child count
Correct handling of containers w/ unknown child count
Status: RESOLVED FIXED
Product: rygel
Classification: Applications
Component: External plugin
git master
Other All
: Normal normal
: ---
Assigned To: Jens Georg
rygel-maint
Depends on:
Blocks: 644491
 
 
Reported: 2011-10-17 12:02 UTC by Zeeshan Ali
Modified: 2012-07-17 06:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
core: INT_MAX children means "Don't know" (1006 bytes, patch)
2012-02-25 15:27 UTC, Jens Georg
committed Details | Review

Description Zeeshan Ali 2011-10-17 12:02:09 UTC
+++ This bug was initially created as a clone of Bug #644491 +++

Currently we report the exact same child count as reported by MediaServer2 implementers, which is G_MAXUINT32 if child count in unknown. UPnP OTOH doesn't have the same semantics so most clients (if not all) will end-up browsing containers for ever.
Comment 1 Juan A. Suarez Romero 2011-11-25 10:00:06 UTC
Some questions:


* In the MediaServer2 spec, in no place it is told that childcount=G_MAXUINT32 means "I don't really know how many children there are". I think this was just commented in bug #644491, but would be good to write it down in the spec.

* I need to understand better what are the behaviour when a UPnP server tells a client there are 10 elements in a container, and then, when the client requests those 10 at the end it can only be returned less elements (just because, for instance, some user deleted some files meanwhile). What is the client behaviour? My understanding is that the client won't enter in a neverending loop, as this case, though not very common, can really happens.
Comment 2 Jens Georg 2012-02-17 12:31:08 UTC
(In reply to comment #1)
> Some questions:
> 
> 
> * In the MediaServer2 spec, in no place it is told that childcount=G_MAXUINT32
> means "I don't really know how many children there are". I think this was just
> commented in bug #644491, but would be good to write it down in the spec.

Will update, that idea just came up in the other bug and was never part of that spec initially.

> 
> * I need to understand better what are the behaviour when a UPnP server tells a
> client there are 10 elements in a container, and then, when the client requests
> those 10 at the end it can only be returned less elements (just because, for
> instance, some user deleted some files meanwhile). What is the client
> behaviour? My understanding is that the client won't enter in a neverending
> loop, as this case, though not very common, can really happens.

That depends. Some clients might stop, others might try to get the exact number of children. Which is stupid, but kind of legal since the child count suggests that there are more.
Comment 3 Jens Georg 2012-02-25 15:27:34 UTC
Created attachment 208408 [details] [review]
core: INT_MAX children means "Don't know"
Comment 4 Juan A. Suarez Romero 2012-02-27 08:35:55 UTC
Couple of comments:

* The MediaServer2 spec should be updated if this is finally approved

* Wouldn't be a good idea to clarify the value of INT_MAX? It's value can depend on the architecture, so clarifying it would be a good idea (i.e., INT32_MAX seems more clear than just INT_MAX).
Comment 5 Jens Georg 2012-07-17 06:49:02 UTC
Attachment 208408 [details] pushed as fd4648a - core: INT_MAX children means "Don't know"