[Standards-JIG] Re: Re: jep-0060 $home

Gaston Dombiak gaston at jivesoftware.com
Wed May 31 20:57:19 UTC 2006


Hey Ralph,

I guess that my post is mixing implementation and specification languages. I 
know that the JEP doesn't mention attributes hence the confusion. My point 
was that pubsub implementations should keep a parent 
"link/reference/attribute/field" in each node that points to its parent 
node. So for example when a client sends:

Example 192. Entity creates a new node related to a collection

<iq type='set'
    from='bard at shakespeare.lit/globe'
    to='pubsub.shakespeare.lit'
    id='create4'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <create node='plays'/>
    <configure>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='pubsub#collection'><value>announcements</value></field>
      </x>
    </configure>
  </pubsub>
</iq>

the pubsub service will create a node with ID "plays" (or with any modified 
ID) whose parent node is the node whose ID is "announcements". The parent 
node is stored as an attribute of the node "plays" instead of altering the 
new node's ID to append the parent node ID thus composing some kind of path. 
Even if pubsub services decide to use the "path" as the node ID then that 
doesn't avoid the fact that each node has to store the node ID of its parent 
as another attribute. The reason for that is that nodes ID cannot be 
modified once created but nodes can have new parents. As you can imagine, 
storing the path as node IDs may mislead users if you later modify the 
parent of the node to be some other node.

Regards,

  -- Gato


"Ralph Meijer" <jabber.org at ralphm.ik.nu> wrote in message 
news:20060531193743.GA63095 at ik.nu...
> On Tue, May 30, 2006 at 04:14:44PM -0300, Gaston Dombiak wrote:
>> Hey Peter,
>>
>> >> In ejabberd the node attribute isn't an id.
>> >> It's more a method like xpath or xpointer or directory+filename to
>> >> access a node.
>> >
>> > NodeIDs are opaque. They MAY have some structure but any such structure
>> > is completely optional.
>>
>> That is correct. Wildfire's implementation ensures that nodes' IDs are
>> unique in the service. Hierarchies (or better say graphs) of nodes are 
>> built
>> based on a parent attribute rather than the ID semantic definition. In
>> summary, we can say that service + node ID is a "unique key" and that 
>> each
>> node has a parent attribute that points to the ID of some other node.
>
> Parent attribute?
>
> -- 
> Groetjes,
>
> ralphm
> 






More information about the Standards mailing list