[JDEV] New Transport Architecture - Idea

Mon Feb 5 10:08:39 CST 2001

Mark Zamoyta wrote:

> For example, lets say a sports fan wants to receive batter by batter
updates
> during a baseball game.  His Jabber server would need a "Sports Update"
> transport.  But as we know, very few people have the technical ability to
> write such a transport.

Writing a transport for every particular application would
be warty. Instead, as Peter Saint-Andre points out, use 
the Rich Site Summary transport. This way, only one transport
needs to be written by the Jabber side, and only one 
publication protocol needs to be implemented on ESPN's side
(consider that they would have multiple subscriber bases, 
each much, much larger than Jabber).

> 4)  The Web Server Transport would poll jabber.espn.com, or it would
receive
> pushes from the web server, passing appropriate HTML along to subscribers.

If ESPN would like to use the Jabber network to broadcast
its scores, the best thing would not to create Yet Another
Complicated Protocol, but Yet Another X Extension. Why not
just send a <message/>? Inside the message, in the body,
describe what happened. If you want to send more 
(structured) information, send something inside an <x/> tag.

e.g.

<message to="joerandom at jabber.org" from="espn at jabber.espn.com">
    <body>Mickey Mantle returns from grave to hit home run!</body>
    <x xmlns="com:espn:jabber:baseball:playerstats">
       <name>Mickey Mantle</name>
       ...
    </x>
</message>

That way clients who don't understand the <x/> tag will 
still be able to read it. Heck, clients who don't understand 
the <x/> tag will still be able to receive it (thus 
increasing your marketshare from nobody to everybody).

XML is good that way. It's easier to extend the <message/>s
than it is the server because you don't *need* to force
code upgrades before you can start using it. Moreover, it's
easy to write another client extension by yourself without
requiring some of the limited resources from the server team. 
Clients are more flexible, less critical when they fail,
faster to develop, and faster to distribute.

I guess I'm suggesting that transports shouldn't be the 
first solution considered.

SS