[jdev] Re: VTD-XML version 1.6

[Michal vorner Vaner]

On Sat, May 20, 2006 at 11:02:43AM -0700, Jimmy Zhang wrote:
> hmm, intesting response, but please excuse my ignorance again as I drum up
> 
> I would like to think that a fault-tolerant architecture, (example, IP 
> routing), should
> have routing information in every message it sent. The assumption that the 
> connection
> would stay alive for days or weeks has a few possible issues
>
> (1) distribute system should be stateless, but if the router replies on the 
> first message to decide
> how to route subseqeunt messages in the session, then that routing info has 
> to stay in memory
> for a long, long time, sounds like a stateful design to me... in contrast, 
> a stateless approach
> will parse XML messages, look for routing info, then route it and garbage 
> collect memory
> and move on to next message..

You don't seem to understand. Every stanza contains information where it
should go. So there is no need for such information.

> (2) for connection oriented protocol like TCP, openning a connection for a 
> few days is also
> a bad idea, because TCP maintains states (ties up resources) on both ends...

Yes, a little bit. However, with moth machines behind a NAT today, do
you have any better idea how to be able to send them data whenever it is
needed? And, besides, closing the connection means changing the state to
offline.

> (3) what if system crashes or the connection resets?

Yes, then go offline and act as if just disconnected.

> The other potential issue has to do what the big environment...
> 1. If other XML apps assume every message is a well-formed document (like 
> AJAX,SOA), they
> may not work well with XMPP because of incompatibility to XML stream... so 
> XMPP would
> likely have to live with that, hindering adoption...

Well, this is XMPP protocol. If an application knows the protocol, it
knows they are not whole XML documents. If it does not know XMPP, it is
not much they could do even if they were documents.

> 2. In the future, XML capability will get built into the network layer, but 
> if a message is not well-formed
> XML, they are less likely to take advantage of those capabilities of 
> network routers and switches, again
> hindering adoption....

Into what network layer? I guess this will not happen. I really want to
see usable switch that understands XML.

And XMPP can still live nicely as TCP protocol. As is HTTP, as are many
others, it is only different what runs on the wire.

It seems you just misunderstand it completely. Could you read the
specifications?

> ----- Original Message ----- 
> From: "Peter Saint-Andre" <stpeter at jabber.org>
> To: "Jabber software development list" <jdev at jabber.org>
> Sent: Friday, May 19, 2006 8:39 PM
> Subject: Re: [jdev] Re: VTD-XML version 1.6
> 
> 
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >Jimmy Zhang wrote:
> >>Excuse my ignorance, after read your examples a bit more, I had only
> >>more questions...
> >>why not exchanging well-formed XML messages for each request and
> >>response like SIP??
> >
> >Because SIP sucks?
> >
> >But seriously, Jabber/XMPP technologies were designed this way from the
> >very beginning (when Jeremie Miller invented them in 1998). It's a bit
> >late to change things now.
> >
> >>for some reason this partial conversation style of XMPP looks pretty
> >>unnatural??
> >
> >Heh, I chatted with Tim Bray about this at a conference a few years ago
> >and he said "well, I wouldn't have designed it that way" -- i.e., he
> >would have sent complete documents, rather than dreaming up something
> >"unnatural" like XML streams. So yes, streaming XML seems unnatural to
> >people who are used to thinking of XML as a document format. Yet there
> >is no really good reason why a message should be a full document, is 
> >there?
> >
> >>Why is XMPP this way??
> >
> >Because. :P
> >
> >But it turns out that streaming XML has some inherent benefits, one of
> >which is that you don't have to create a new parser instance every time
> >you want to send, receive, or route a message.
> >
> >Peter
> >
> >- --
> >Peter Saint-Andre
> >Jabber Software Foundation
> >http://www.jabber.org/people/stpeter.shtml
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v1.4.1 (Darwin)
> >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> >iD8DBQFEbo+JNF1RSzyt3NURAk4oAKCJ6GLqc4H/NF4DZuYWJpztIy5xyQCcCP7Y
> >i/V52aUC64GWUTfBORKVbWQ=
> >=5To2
> >-----END PGP SIGNATURE-----
> >
> 
> 
> 
> 

-- 

Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20060520/9f0c64c1/attachment-0002.pgp>