[jdev] Single host, multi service.

[Ralph Meijer]

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 user at example.com, then you could
> > have user at example.com/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...
> 
> trejkaz at jabber.zim.net.au/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