From: Adam Rifkin (adam@KnowNow.com)
Date: Thu Dec 28 2000 - 17:06:48 PST
Jeremie Miller said to XML Magazine:
> E-mail servers act 100 percent on a peer-to-peer basis. Every e-mail
> server -- SMTP server -- can talk to every other SMTP server equally in
> a network.
Then why was the TURN command invented?
> Since we're not doing HTML or XML GUI display, and we don't really
> have any scripting languages in the client, there's no reason to have
> a Document Object Model . . .
The ability to script the DOM is one of the reasons the Web is such a
powerful platform.
> Jabber is just a generic XML-routing framework;
Jabber is just a generic XML-switching framework.
> Web browsers weren't really designed to be able to receive these
> real-time events and handle sockets in the way that we do. They're
> really a "pull" sort of model. The action has to be initiated inside
> the Web browser, so it's difficult to map some sort of Instant
> Messaging model into a Web browser because they just weren't designed
> to do that.
I respectfully disagree.
http://www.xmlmag.com/upload/free/features/xml/2000/05win00/sg0005/sg0005.asp
> More Than Just Jabber
>
> Although Jabber was designed as an instant messaging system,
> its XML architecture enables it to do a whole lot more
>
> by Steve Gillmor and Sean Gallagher
>
>
> Jabber is an open-source, cross-platform, XML-based instant messaging
> system that lets users communicate by text, voice, multimedia, or
> application-to-application. Editorial director Sean Gallagher and editor
> in chief Steve Gillmor talked with Jabber founder Jeremie Miller about
> Jabber's XML architecture.
>
> Miller: If you look at instant messaging as it started out, the clients
> are really just applications that send messages and receive presence,
> send and receive different sorts of data, and display them to the
> user. On the server side, the server communicates to various Instant
> Messaging services transparently for you. So different services also
> speak, translate, and deal with this data and then deliver it to these
> applications.
>
> If you look at it generically, even though it's an Instant Messaging
> platform, it's really a platform that delivers XML fragments between
> services and applications, and applications and applications. You start
> to realize that there's a lot more uses for this type of model than just
> simple Instant Messaging.
>
> Gillmor: For example?
>
> Miller: Whiteboarding document sharing inside of a Web browser --
> collaborative browsing, they call it. A lot of applications already do
> this. But what we're building is one generic architecture that can
> really handle the back end for all sorts of those applications. Say
> you're in Palm Pilot and you want to sync your address book. If you had
> your address book defined in XML -- working with SyncML synching it up
> to your server -- these applications might be using Jabber to send or
> receive these things on the fly. When you update your address book in
> one application, it's automatically pushed out to the server. The server
> announces the change to all the other applications listening to that
> XML, and they receive those updates.
>
> Gillmor: Why XML?
>
> Miller: Back in 1998 when I started working on it, there were different
> open-source libraries out there that already were reverse-engineered to
> talk to different Instant Messaging services -- AIM, ICQ, and Yahoo. To
> communicate with them, you had to build one client that used all these
> libraries in a different way. If you look at the traffic that is
> happening in Instant Messaging, it's simple messages, it's simple
> presence, and it's a Buddy List. Defining that data generically so that
> you only have to build a client once seems like an excellent application
> for XML.
>
> Gallagher: How has Jabber been extended beyond the traditional Instant
> Messaging/chat-type functionality?
>
> Miller: We have built extensions to the RSS (Rich Site Summary) XML
> format. There are thousands of sites out there now publishing headlines
> and little news stories in RSS -- SlashDot, CNN, and various
> others. Using a Jabber client, you can tell this RSS agent to track
> certain sites for you, and it will automatically send you the headlines
> as soon as it sees them.
>
> Gallagher: When you request something from the RSS agent, is that
> integrated into the client application itself or is that done on a
> server-side-type agent?
>
> Miller: Right now, it's done on the client side. All the clients have a
> generic registration screen so they can register with an agent. You can
> register with an ICQ or AIM transport and configure it to work on your
> behalf so that you can communicate with people on both services.
> Whenever you start up a client -- any client, anywhere -- it
> automatically pushes those headlines to you.
>
> Gillmor: Is that presented in the same way that an AIM user would get a
> ticker, or in the body of the window as text?
>
> Miller: Both ways. Any client can display it as text, but a client that
> has the ability to use the extra XML inside the message can intercept
> that message and display it in a ticker format or whatever UI that they
> want to.
>
> Gillmor: Can that be consumed by a server and then republished as DHTML,
> for example?
>
> Miller: Sure. The recipient could be another server, displaying that on
> another Web site -- the Web-services type of model.
>
> Gillmor: Do you have an edge-server philosophy as part of the Jabber server?
>
> Miller: As far as the Instant Messaging world goes, there hasn't been a
> big requirement for it. The next generation of the server that we've
> been writing can be bundled and included with any client; we're bringing
> the server and client closer together.
>
> Gillmor: It begins to sound like peer-to-peer.
>
> Miller: Exactly. On a server-to-server level, Jabber is peer to peer,
> and we are bringing these servers closer to the client so that it is
> more transparently a peer-to-peer technology. If you look at Instant
> Messaging in general, the technology might be server centralized, but
> from a user point of view, the interaction is peer to peer in the same
> way that Napster, from a user point of view, is peer to peer, even
> though there is a central server.
>
> Gillmor: Do you see any utility to the peer-to-peer model that goes
> beyond what traditional client-server applications do?
>
> Miller: When you look at e-mail servers, they act 100 percent on a
> peer-to-peer basis. Every e-mail server -- SMTP server -- can talk to
> every other SMTP server equally in a network. From the server to the
> client, there's a client-server relationship. But server to server, it
> is a peer-to-peer network. If you look at routing of the Internet,
> routers are basically a peer-to-peer network. Peer to peer is really the
> only thing that can scale back-end systems to a world-wide scale.
>
> Gallagher: How easily can you adapt Jabber as a transport for other
> XML-formatted data?
>
> Miller: To answer that, let me first describe how XML works inside
> Jabber. In an Instant Messaging system, the client needs to establish a
> relationship with the server and needs to maintain that relationship --
> saying that you're online -- and the server needs to be able to generate
> messages at any time and deliver them to the client. We're doing that
> with just one simple TCP socket. Any client can open a TCP socket to
> the server.
>
> Then we had to decide how to send that data back and forth. We knew we
> wanted to use XML and we knew the client and server needed to be able to
> send it, both asynchronously, at any time. At the time we did this,
> there weren't really any other transport layers out there to do
> that. HTTP doesn't work in that model. SMTP could be used in that model,
> but isn't quite as asynchronous as we wanted.
>
> What we decided to do was simply call this TCP socket an XML document,
> so that at the beginning of the relationship, you send a fragment of XML
> down -- the root tag of the document. You parse that on the fly on the
> other side, such as any SAX-based parser can do.
>
> On top of this XML stream, we defined three protocol types: messages,
> presence, and InfoQuery (IQ). InfoQuery is a generic wrapper around any
> other XML -- a Buddy List or a V-Card -- a way of saying this is some
> extraneous data that is not a message or presence. You can insert your
> own custom XML inside of a message, or inside a presence, and you put
> that in your own name space.
>
> Gallagher: I can use anything that's inside the IQ tags, for example,
> for other types of method calls or things like that from client to client?
>
> Miller: Sure.
>
> Gillmor: Can you wrap SOAP calls inside of the IQ tags?
>
> Miller: Absolutely, and we've been playing with that, as well as having
> an HTTP transport on the server side that converts the wrapped calls
> back and forth to real SOAP calls. If you look at any of the XML
> namespaces, any of the DTDs out there, you can put that XML inside any
> of these messages, presence, or IQ -- and you can build services on the
> server side that are either generating this XML, or inserting it in
> there, adding value to the conversations that you're having. If the
> client understands that XML, you can display it; if not, it's hidden --
> you're only getting the message.
>
> Gallagher: How simple would it be for someone to add a Jabber interface
> to an application to act as a member of a chat, show up on someone's
> Buddy List, and interact through Jabber messages with a user?
>
> Miller: I'm looking forward to being able to build those
> applications. There's nothing difficult about that at all.
>
> Gillmor: Can the Jabber framework become conversant or a part of another
> framework such as Ray Ozzie's Groove architecture?
>
> Miller: Jabber was designed, fundamentally, to be protocol agnostic. On
> the server side, we take these generic pieces of XML and convert them
> into other transport layers -- dropping them onto the ICQ network or
> another Instant Messaging network. We have SMTP gateways and HTTP
> gateways that we're building SOAP and XML RPC into. Adding an additional
> gateway, such as going to the architecture that Ray Ozzie has been
> building, is just a matter of accessing that network and then having
> some sort of translation on the server side between the XML in Jabber
> and the XML or whatever data format they're using. The advantage is that
> a Jabber application or client transparently has access to everything on
> that network because the translation was done on the server
> side. Nothing needs to be changed or added into an application built on
> top of Jabber to be able to add support for any of those additional networks.
>
> Gillmor: Are you using the Apache tools -- the parser and the XSL engine?
>
> Miller: The server is C-based, so we're using the C-based parser written
> by James Clark. The Apache tools are being used for parts of the project.
>
> Gillmor: Is there any support for the Document Object Model?
>
> Miller: Since we're not doing HTML or XML GUI display, and we don't
> really have any scripting languages in the client, there's no reason to
> have a Document Object Model . . .
>
> Gallagher: You really just need the event model from SAX.
>
> Miller: Yes, to pull out our messages and presence. Then if you have a
> custom display for the different XML that you're pulling out, you'll be
> doing whatever you need with that.
>
> Gillmor: Do you have any plans to include your protocol feed, if you
> will, in a browser directly, as opposed to a separate Instant Messaging client?
>
> Miller: There's a Mozilla Jabber client in the works -- a component that
> plugs in so that Mozilla, as a platform, can take advantage of
> Jabber. But Web browsers weren't really designed to be able to receive
> these real-time events and handle sockets in the way that we do. They're
> really a "pull" sort of model. The action has to be initiated inside the
> Web browser, so it's difficult to map some sort of Instant Messaging
> model into a Web browser because they just weren't designed to do that.
>
> Gillmor: What about bandwidth considerations, having this open document
> in the stream?
>
> Miller: We did calculations based on all the traffic that's been going
> in and out of the Jabber.org and Jabber.com servers, and you could
> easily run Jabber over a 300-baud modem. People say XML is heavy, but
> the way we're using it -- and it's not even compressed -- XML has very
> minimal impact on the bandwidth.
>
> Gillmor: What about security, encrypting the traffic?
>
> Miller: The server supports SSL; it's optional for the clients. We've
> just defined an option wherein clients can encrypt or sign their
> messages and presence, and include additional XML inside those
> messages. You can put XML at any point anywhere in messages or presence.
>
> The Jabber architecture is ignorant of the XML that's flying around.
> It's up to the services and the applications take advantage of it.
> Jabber is just a generic XML-routing framework; it's based on some sort
> of user identity so that you can communicate with another person and
> that person's applications, instead of just a URL or an IP address.
>
> Gallagher: Because you've kept it basic, that's opened up the number of
> potential uses.
>
> Miller: We're excited about building those potential uses. We have
> little pieces that translate your chats for you into other languages on
> the fly, and that build in a lot of different Web services. When I first
> saw XML back in '97, it clicked right away: in the future, almost all
> application data will be defined in XML. The more that we can enable a
> network that is aware of this XML -- enable it to route XML
> intelligently and pass it between different points that need to interact
> with it -- the more advantageous it will be for people to build XML into
> applications.
>
>
> Steve Gillmor is the editor in chief of XML Magazine. He can be reached
> at sgillmor@fawcette.com.
>
> Sean Gallagher is the editorial director of XML Magazine. He can be
> reached at sgallagher@fawcette.com.
---- Adam@KnowNow.ComNames come to mean something; having those names diluted is not good for the creative process. It can create confusion and stop forward motion, and penalizes generosity. There's a limit to how open one can be.
For example, I could write "The Cathedral and the Bazaar 2.0" but no one would buy it because I didn't write version 1.0. We must respect an author's ability to finish a thought. One would think this is self evident, that all people with a long-term investment in creativity would follow this rule, but I don't believe it works that way in real-world business. When money is involved, people don't always respect creativity (ask Courtney Love, Roger McGuinn, Prince, or Chuck D).
So my advice to creative technology people who want to be able to continue their work -- learn how trademark law works and use it. Trademarks are not like patents; they don't stop people from building on or improving on your work. However they do enforce a base level of fair play, no one can say they created your creation. Where patents kill creative processes, trademarks are good for creativity. Use them.
-- Dave Winer, http://www.xmlmag.com/upload/free/features/xml/2000/05win00/dw2_0005/dw2_0005.asp
This archive was generated by hypermail 2b29 : Thu Dec 28 2000 - 17:11:36 PST