[standards-jig] Server-side packet routing
dave at dave.tj
Thu Mar 14 06:44:17 UTC 2002
Isn't there a mailing list for JabberNG somewhere?
Iain Shigeoka wrote:
> 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
> 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
> > 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
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards