>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?
The spec is a onetime trabsported/installed, configuration file. It is used
to contruct the application, and/or configure its execution and that is the
only time it is used. If you want to transport binary data, fine. If you
want to GSM compress audio fine. I am a proponent of simple, non-verbose
information transmission. We do our business in markets where margins are
everything. Anything that costs more per site is a problem for us....
>XML is best suited for static storage and transport of data between
>*dissimilar* applications/processes... in fact, that's what it was designed
>for.
>
>I feel fairly strongly that we need a far more efficient and small/fast
>protocol, which XML is not.
Computers were designed to target weapons, but they ended up being useful for
other applications as well :-) XML is infact great for neutralizing data
representations and labeling and containerizing it. The strict syntax, and
the ability to use a DTD driven editor to control its content, also makes it
good for configuration specification, where the configuration is complex and
the user always does better when helped by a tool. Rather than writing a new
configuration management GUI for each application, why not just design a DTD,
and let the user use their favorite XML editor so that you don't have to make
that part of the cost of your software? You also let those that design UI's
good, compete at that, and you can compete with a lower cost in your market...
-----
gr...@cy... (Cyte Technologies Inc)
|
