Coherence uses 1000 as the parentID for the root's children

the root container doesn't have to have the id '0', it actually can be anything and is backend implementation specific.

It is only the Browse action, when queried with id set to '0', is supposed to return the root-container.

The Content Directory spec implies that the root node is "0".

How do you propose clients build a tree if the root node has two IDs, one known (0) and one secret (1000)? Can you cite any other upnp media servers which do not call the root node "0"?

Replying to iain:

The Content Directory spec implies that the root node is "0".

in the spec is written for the Browse action: An ObjectID value of zero corresponds to the root object of the ContentDirectory service.. There are two other occurrences of the value '0' for accessing the root container. If you find in the spec a statement that explicitly states that the root-container must have an id of '0' pls provide that.

How do you propose clients build a tree if the root node has two IDs, one known (0) and one secret (1000)?

clients usually build the tree by browsing with the BrowseDirectChildren? flag. And neither the clients I've worked with nor the ones I've build have any issues with that.

Can you cite any other upnp media servers which do not call the root node "0"?

no, but that doesn't imply something being right or wrong. ;-)

Anyway, if you have reasonable doubts, I'm of course open to discuss a change.

Replying to dev:

Replying to iain:

The Content Directory spec implies that the root node is "0".

in the spec is written for the Browse action: An ObjectID value of zero corresponds to the root object of the ContentDirectory service.. There are two other occurrences of the value '0' for accessing the root container. If you find in the spec a statement that explicitly states that the root-container must have an id of '0' pls provide that.

I would take it that because the spec only uses 0 as the root node and the browse action's docs say that it corresponds to the root node (as you quoted above) that would mean that the root node is to be "0", as there is no way as far as I can tell, to obtain the root node ID that it makes sense to be a well known and documented value: "0"

How do you propose clients build a tree if the root node has two IDs, one known (0) and one secret (1000)?

clients usually build the tree by browsing with the BrowseDirectChildren? flag. And neither the clients I've worked with nor the ones I've build have any issues with that.

Well, the issue I'm coming up against is that I have to put hacks in place to support Coherence. There are two ways that I can see to build a tree:

For example: Browse ("0") -> Create node for "0" Root node has one child "1" Browse ("1") -> Create node for "1" Attempt to put "1" into the tree, by looking up its parent All other media servers return parentID = "0", all is well Coherence returns parentID = "1000". There is no node for 1000.

Now, I can put a hack in place that means I then browse "1000", find out that it has no parentID, decide that "1000" is now the new root node and start all over again. But that is a hack, and a hack that so far only Coherence needs.

Or, I can change the algorithm for building the tree, and pass the parent node into the function that calls the Browse action so that we don't need to look up the parent as we already have it. But then the root is still going to be called "0" which will break things when ContainerUpdateIDs is changed as Coherence will refer to the root as "1000" and we don't have a node for that.

Can you cite any other upnp media servers which do not call the root node "0"?

no, but that doesn't imply something being right or wrong. ;-)

I'd take it as a very large suggestion as to the correct interpretation of the spec.

Anyway, if you have reasonable doubts

I feel I do, and hopefully I've expressed them coherently ;)

Well, the issue I'm coming up against is that I have to put hacks in place to support Coherence.

where do you would need to put the hacks in?

Anyway, if you have reasonable doubts

I feel I do, and hopefully I've expressed them coherently ;)

your explanation does really help to understand the reasons for opening this ticket

Or, I can change the algorithm for building the tree, and pass the parent node into the function that calls the Browse action so that we don't need to look up the parent as we already have it.

building a tree based only on the @parentId might fail anyway if you look for example at the reference items.

The specs states there: The reference item MAY have a different @parentId property value.

Meaning there could be in the reference item the same @parentId as in the referenced item, or the @parentId of the container the reference item is within.

Replying to dev:

Well, the issue I'm coming up against is that I have to put hacks in place to support Coherence.

where do you would need to put the hacks in?

To detect that the root node isn't called "0" but is called "1000", and either start again, or somehow replace the root node in my own representation

Replying to dev:

Or, I can change the algorithm for building the tree, and pass the parent node into the function that calls the Browse action so that we don't need to look up the parent as we already have it.

building a tree based only on the @parentId might fail anyway if you look for example at the reference items. The specs states there: The reference item MAY have a different @parentId property value. Meaning there could be in the reference item the same @parentId as in the referenced item, or the @parentId of the container the reference item is within.

That seems fine to me when building a tree as the reference item may not need to be in the same container as the item it references (and I've got that situation working fine).

If we cannot use @parentID how do you trust @ContainerUpdateIDs, which gives the Id of the container that has changed?

If there was an action to obtain the name of the root container, then I wouldn't care that much, but there isn't, and the other media server authors I've spoken to have all said "0" is the name of the root container.

Looking at it from a different perspective, is there a reason why Coherence doesn't use 0 as the name of the root container, or is it just that it makes whatever algorithm is used to generate the IDs simpler?

Replying to iain:

Replying to dev:

Well, the issue I'm coming up against is that I have to put hacks in place to support Coherence.

where do you would need to put the hacks in?

To detect that the root node isn't called "0" but is called "1000", and either start again, or somehow replace the root node in my own representation

my question was maybe misleading, it was targeting your application/software/project/product/...

Replying to dev:

my question was maybe misleading, it was targeting your application/software/project/product/...

You mean what am I writing? I'm afraid I can't tell you, sorry.

hello, this one discussion was interrupted quite abruptly. And we still do not know whatever ian was working on. :-)

I won't enter the right/wrong debate about using other IDs than 0 for the root item, as it is more or less a "specification" issue, and specifications are and will always be .... specifications, whatever polished they are.

However, ian had a point about the @ContainerUpdateIDs thing: when a given container may be published to clients and browsable through several IDs (namely the FSStore root container which can be browsed through IDs '0' and '1000'), it is fair to believe that in case an update event is published about this container, this event is duplicated for all the IDs. That way, it is lost to no one. Is it the case within our framework?