[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Binary XML
- From: Stuart Naylor <firstname.lastname@example.org>
- To: 'Michael Brennan' <Michael_Brennan@allegis.com>
- Date: Thu, 26 Jul 2001 22:09:44 +0100
I thought the only way you could get binary through port 80 is in a mime
wrapper. This gives it a layer of encapsulation in a effort to render it
Port 80 is text only even if you can hide binary in wrapper it still is
a text tranfer but how would this work with binary xml.
Would this also be included in a wrapper so we have a unicode protocol
represented as binary then wrapped in a mime type to be unwrapped so
that processing can occur ?
From: Michael Brennan [mailto:Michael_Brennan@allegis.com]
Sent: Thursday, July 26, 2001 9:36 PM
To: 'Stuart Naylor'; email@example.com
Subject: RE: Binary XML
The issues with COM and CORBA through firewalls has nothing to do with
fact that they are binary protocols. It has to do with the way these
protocols use ports, and the fact that many firewall configurations only
permit traffic through particular ports (and sometimes filter traffic
does not conform to a specific protocol, such as HTTP). In contrast,
pretty ubiquitous and sticks to its designated port. Contrary to some
HTTP can be used to carry any type of content -- binary or otherwise.
is really not particularly well suited for some of the purposes for
is being used, but it's there and it's easy to piggy-back other
top of it.
With that said, much of the talk of "binary XML" is misguided, IMO.
is, unfortunately, widespread ignorance of what prevailing, established
protocols already provide for solving many of the problems that "binary
is supposed to address. Some of the suggested use cases include:
1) A binary protocol can be more efficient to parse into in-memory data
objects. I think this is bogus. When sending over a WAN, network latency
will make this parsing overhead insignificant. On a high-performance
situation that needs that extra efficiency may be better served by using
CORBA, COM, or a similar RPC mechanism. XML is not a panacea, and not
problem needs an XML-based solution. The valid use cases for this are a
fraction of what some suggest, IMO.
2) Faster throughput over a WAN. There are already established ways of
dealing with this. The HTTP spec explicitly supports compression using
proven protocols (gzip, deflate). These same compression protocols could
used over other transport protocols, as well. Inventing a "binary XML"
format purely for this reason is simply pointlessly reinventing the
3) Providing optimized random access to fragments from large documents.
one is interesting, but is probably better served in the more general
by XML databases, which is an evolving area.
> -----Original Message-----
> From: Stuart Naylor [mailto:firstname.lastname@example.org]
> Sent: Thursday, July 26, 2001 11:23 AM
> To: email@example.com
> Subject: Binary XML
> Can someone explain to me the idea behind binary XML.
> My initial interest in XML was due to the pitfalls of using binary
> distributed objects such as COM / CORBA. The protocols worked fine but
> had major problems when presented with a firewall and
> security settings.
> I am just interested in how binary XML will circum-navigate all the
> security scares that the doom & gloom consultants attach to binary