[standards-jig] Server-side packet routing

Iain Shigeoka iainshigeoka at yahoo.com
Thu Mar 14 05:51:41 UTC 2002


On 3/13/02 9:36 PM, "Dave" <dave at dave.tj> wrote:

> In that case, I can't wait for JabberNG :-)
 
:)  Me too.  I have no idea how we're supposed to start working on JNG
though.  Hopefully the brouhaha in the JSF members list will provide some
guidance once that's settled down.  We had started to talk about both pure
pub-sub routing and framing as the subject comes up but nothing cohesive
yet.

If you've got ideas though, you might as well toss them out as they come so
we can chew on it.  That's what I've been doing.  A lot of it will probably
percolate on the backburners for a bit but its good to bounce the ideas
around...

-iain

> Dave Cohen <dave at dave.tj>
> 
> 
> Iain Shigeoka wrote:
>> 
>> 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
>> packets.
>> 
>> 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.
>> 
>> -iain
>> 
>> 
>> _________________________________________________________
>> Do You Yahoo!?
>> Get your free @yahoo.com address at http://mail.yahoo.com
>> 
>> _______________________________________________
>> Standards-JIG mailing list
>> Standards-JIG at jabber.org
>> http://mailman.jabber.org/listinfo/standards-jig
>> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig


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




More information about the Standards mailing list