[standards-jig] Server-side packet routing

Julian Missig julian at jabber.org
Thu Mar 14 23:17:33 UTC 2002


You make a very good point, and I definitely think it's worth
considering -- especially when some of these changes are very simple
things. (It's more difficult to justify the ones which would take a lot
of time and effort, but even then how will we know if it really works
until we implement with JNG?)

Julian

On Thu, 2002-03-14 at 01:54, Mike Lin wrote:
> JNG is supposed to be some cathedrally-designed version of Jabber that
> fixes the problems we are seeing today. A lot of these are brand new
> problems that, if we solve them, we'll be solving for the first time.
> IMHO we won't really know how to do this until we at least try to hack
> in fixes to some of these problems in Jabber as it stands today. I don't
> think anyone knows what the best solution is for the routing problem and
> I don't think we can figure it out by going back and forth on a mailing
> list. There are other problems we are facing as well, such as those
> addressed by the recent JEPs 11, 17, 20, 21, 23, and 24.
> 
> It's my opinion that in order to solve these problems we will need to
> have "boots on the ground" so to speak - implement various solutions and
> see what works and what doesn't, because no one knows by a priori
> inspection.
> 
> -Mike
> 
> On Thu, 2002-03-14 at 00:51, 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
> > 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





More information about the Standards mailing list