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