[standards-jig] Pub/Sub for JNG?

Iain Shigeoka iainshigeoka at yahoo.com
Wed May 1 17:33:01 UTC 2002

Wow, this thread sure has taken off.  :)  

1) compressed streams

I'm mixed on this.  As mentioned earlier, it was shown
that you can compress Jabber streams to lower bandwidth.
IM servers are typically network bound so the computation
overhead of compression should not slow the overall
performance of the server.

I believe the last time this came up, it was eventually dropped
because the benefits just didn't justify the added complexity.

Ideally, I suppose we should try to make this a negotiable
transport feature.  It seems to come up enough that no
matter what the group decides, there will be enough people
in the other camp that will want to do the opposite.

I believe we can design a transport system that can accomodate

2) UDP

Technically, I think UDP is good idea.  Especially in situations
where we could exploit multicast.

I imagine that the main reason people avoid it though is difficulty
in making a good implementation based on UDP, and firewall
issues.  The latter would seem to me to be the largest issue.
For all its technical advantages, I think UDP is simply a non-starter
for us if we want to get inside enterprises.

3) transport switching

Switching transport layers would be really nice to have.  I'm
not sure how you would do it in practice but would be interested
in seeing a proposal for details in this direction.

Perhaps simply standardizing multiple transports of the Jabber
protocols is the way to go.  Then an HTTP Jabber client would
just have to know where an HTTP Jabber server was and use
it.  That way, servers/clients won't have to support some 
bootstrap protocol to negotiate transports.

The down side being multiple transports effectively fragments
the Jabber network into transport "islands".


Do You Yahoo!?
Yahoo! Health - your guide to health and wellness

More information about the Standards mailing list