Brill said:
> Like I keep saying... why does it have to be XML? there is no real
> advantage in this application. Should you want to interface XML for
> normalized transport to *external* applications, conversion would be a
> fairly simple task... so again, why must the "native" protocol use XML?
> What point to it except wasting memory, speed and bandwidth?
There would be very little memory or speed wasted, and the packets would not
be very big, so likely bandwidth would not be an issue either.
> XML is best suited for static storage and transport of data between
> *dissimilar* applications/processes... in fact, that's what it was
> designed for.
And embedlets will be connecting to all sorts of back end systems. J2EE,
.NET, Legacy mainframe, and others. The whole world is using XML for this
and it looks like it will only get more usage over time.
Why fight an entrenched standard, that will confer more benefits than not, with
little downside for the majority of situations?
> I feel fairly strongly that we need a far more efficient and small/fast
> protocol, which XML is not.
Then you will be perfectly able to write your own embedlet protocol/packaging
adapter to use for those applications that absolutely demand the ultimate in
performance (most of which won't, in my opinion).
Plus what Gregg said!
I intend to ensure that we/I deliver an Outpost specification/container that has
external communications based on HTTP and XML first.
After that...go nuts! The architecture will be modular enough to support other
transport methods.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
