[Standards-JIG] Proposed Changes to JEP-60 - PubSub

CORVOYSIER David FTRD/DMI/REN david.corvoysier at francetelecom.com
Fri Jun 4 08:45:43 UTC 2004


Bob Wyman wrote:
> 	Personally, I believe that nodeID's should be opaque 
> strings. If nodes are to have semantic relationships to each 
> other, then these relationships should be explictly stated 
> via metadata -- not buried into nodeId's themselves. 

If you don't mean using disco, could you give an example ? Or a pointer
to a generic way to describe a node hierarchy using metadata and how it
can be related to pubsub ?

I have been trying in the past few weeks to build a notification service
for events related to a jabber session using pubsub.

I have two issues to solve (both are related actually):

Issue 1:
How can I efficiently assign NodeIDs knowing many jabber sessions will
publish the same 'kind' of data in the service, and that it would be
nice to be able to distinguish between nodes for a given session ?

Possible solutions:
- use instant nodes. Pros: Very simple mechanism. Cons: All nodes look
the same, so I may have troubles trying to solve Issue 2 (see next
paragraph),
- the NodeID have semantic meaning, using a 'flat' distribution: each
node type has a generic node name that is instantiated for a particular
jabber session with an ID built upon the full JID (ie
'generic/mp3-player' is instantiated into
'generic/mp3-player#stpeter at jabber.org/Home'),
- the NodeID have semantic meaning, using a 'tree' distribution by data
type. The pubsub service has two kinds of nodes: generic container nodes
whose items contain the actual information ('generic/mp3-player'
contains 'generic/mp3-player#stpeter at jabber.org/Home'). 
- the NodeID have semantic meaning, using a 'tree' distribution by
session. The pubsub service has two kinds of nodes: session container
nodes whose items contain the actual information
('stpeter at jabber.org#home' contains
'generic/mp3-player#stpeter at jabber.org/Home'). 

The last three solutions are variants of the same concept, and may be
left to the implementation, so there are actually really two options:
instant nodes versus semantically significant NodeIDs. 

Issue 2:
How can a subscriber retrieve the set of pubsub nodes related to a
session, ie related to a full JID ?

Possible solutions:
- only the client that owns the jabber session is able to do the
correlation, because it creates/publishes nodes. Every subscriber must
use disco on that session to retrieve the nodes related to it (BTW this
would probably require a new identity category 'server' type 'session'
or something like that for these nodes).
- the pubsub service is able to do the correlation, so that you can
subscribe to the nodes owned or published by a given full JID (maybe
this is too far away from the JEP-060 spirit ...), 
- the NodeID have semantic meaning, so that a subscriber can 'guess' the
NodeIDs knowing the full JID.

Now if I want to solve both issues, I have the possible combinations:

- instant nodes + disco (the regular way),
- instant nodes + jid-driven subscribe (is this that evil ?)
- well-known NodeID assignment policy (can it be done in a generic,
clean way ?).

Thoughts & comments warmly appreciated ...

David Corvoysier

  



More information about the Standards mailing list