Re: [Fresco-devel] [ReFresco 02] Pre-existing alternatives to CORBA

Nathaniel Smith <[email protected]> Mon, 19 Jan 2004 03:20:40 -0800
Newsgroups gmane.comp.video.fresco.devel
Message-ID <[email protected]>
On Mon, Jan 19, 2004 at 10:47:44AM +0100, Tobias Hunger wrote:
> Nathaniel Smith <[email protected]> wrote:
> > Mbus: http://www.mbus.org , http://www.ietf.org/rfc/rfc3259.txt
> >   - Haven't looked at in detail; seems oriented towards many-to-many
> >     communications, with a fairly inefficient protocol (sequence
> >     numbers represented as ASCII strings?)
> 
> The advantage of an all-ASCII (or UTF8) based protocol is that it is fairly
> easy to debug. XML gives the bonus of being able to use all those XML-tools
> to verify message integrity/well formedness (is that even a word?)/etc.
> 
> With bandwidth and CPU time becoming cheaper all the time and developer time
> for debugging staying at the same level that might be something we should
> consider if we decide on rolling our own system.

Mmm, I don't think I agree.  Bandwidth isn't _that_ cheap, and will
remain expensive for some cases for a long time (think portables, for
example).  And really, if what you want to do is communicate a list of
floating point numbers, a format like
  <length of list as 4-byte integer> <IEEE double> <IEEE double> ...
is going to be orders and orders of magnitude faster than parsing out
  <list>
     <float>303.309</float>
     <float>-3.01e9</float>
  </list>
I mean, we're talking thousands and thousands of cycles, with
complicated parsing and error checking and watching for entities and
handling whitespace and so on, as compared to, like, 2 cycles per list
item.  It's kind of crazy, and it's not like we don't need speed at
all: marshalling/unmarshalling binary data is already slower than one
would like, and think of how many times a second the gimp will want
to know exactly where your mouse pointer is... Even the BEEP people
don't try to use XML as a framing protocol.

For that matter: do you even know off-hand how to properly
serialize/deserialize, say, IEEE doubles to text?  You can't use any
standard library code that I'm aware of, because it's really not a
standardized thing.  Will you lose precision?  Do you properly handle
NaN's and suchlike?  Do you want to write this code a dozen times?

And then you get into binhex'ing real binary data so you can include
it in XML.  And don't forget that strings have to be quoted to
transfer properly.

I think a demarshaller with lots of assert statements is going to be
at least as useful for debugging, without dragging us into the vortex
of twisty XML standards, all different and subtley interacting...

It's not even like "okay, now write an integer into the send buffer"
is really the most error-prone code out there, and it's very easy to
get good test coverage.  Switching to XML would probably make me more
worried, rather than less, about weird bugs.  Software I can hold in
my head makes me confident.  Software where someone's going to someday
discover that we forgot to correctly specify the whether exponent
specifiers were upper or lower case, or we misquote ampersands in some
edge case allowing people to put carefully crafted text onto a web
page that causes your web browser to send maliciously broken messages
to the server... that makes me less confident.

-- Nathaniel

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff