[standards-jig] Server-side packet routing

Iain Shigeoka iainshigeoka at yahoo.com
Thu Mar 14 03:11:31 UTC 2002

On 3/13/02 3:30 PM, "Julian Missig" <julian at jabber.org> wrote:

> Dave Smith noted to me that dave at dave.tj expressed the opinion that
> clients should be able to control "all the routing decisions" -- I do
> /not/ agree with this. The entire point of the server is to do routing.
> Clients should be able to provide information about themselves so the
> server can be more intelligent about routing, but allowing clients to
> control routing gets messy.

I think it is only messy with our current messaging model (point to point,
store and forward).  If we are willing to change that, then there are very
elegant ways to allow clients to completely control routing.

Imagine for example, a pure pub-sub model.  People sending messages to you,
publish Jabber packets to a server packet channel only you have read access
to.  Incoming packets are sorted into subchannels by the server by type
(packet element name and namespace for example) or other criteria (packet
size, sender, etc).  Your clients can subscribe to the main channel (receive
everything) or subchannels depending on what you're interested in.
Subscriptions can be transient (as long as you're logged in), or persistent
(store and forward packets while you're offline).  Multiple clients can
subscribe to the same queue allowing you to receive duplicate copies of

For example, you may want to receive <message> packets on your pager only
when its "activated" with no store and forward (transient sub to <message>
subchannel) AND receive all packets to your desktop client (persistent sub
to main channel).

The server only knows its channels, and manages publishers and subscribers.

We were starting discussions of such a system on JAM or RPC jabber lists but
things sort of died out when we decide this was something to be considered
for jabber: next generation.


Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

More information about the Standards mailing list