On Wed, Sep 28, 2005 at 11:43:23AM +1000, Trejkaz wrote: > >> Sometimes I think it would have been neat if nodes were part of JIDs in > >> the first place... then each service could have been a node off the > >> server's own JID, and everything would be happy. Well, maybe. > > > > For pubsub, JEP-0060 section 4 (Addressing), mentions how you can do > > this by putting the node identifier in the resource part of the service's > > JID. Any pubsub node identified by NodeID at pubsub service example.com > > would be addressable using the JID example.com/NodeId. If you have a > > personal pubsub services (virtual?) for [EMAIL PROTECTED], then you could > > have [EMAIL PROTECTED]/NodeID point to the NodeID node for this user. > > That covers PubSub, but I was more talking about doing it in general. > > If the above rules applied in all cases, the JID for the commands service > running off my current Psi instance would be... > > [EMAIL PROTECTED]/work/windows/http://jabber.org/protocol/commands > > Because of course, that commands node is a different node at each > resource, so merely putting it after the bare JID wouldn't suffice.
Right, this is problematic. I don't have a quick solution there. > > Note the a 'Jabber Server' is really just some entity > > that provides a s2s service. For example, a pubsub service could just as > > well be an application that implements s2s. > > Indeed. In a way, I wish it were common to do it this way instead of > hanging all the components like dongles off the main server. You wouldn't > even need the component protocol at that point. SRV entries would already > let us run every component on its own port for direct contacting. Of course jabberd 1 has always supported components that are directly linked in. Those components don't use the component protocol. I still believe there is value in having that protocol though. Exposing components directly via s2s has disadvantages, too. -- Groetjes, ralphm
