[
Lists Home |
Date Index |
Thread Index
]
David Megginson wrote:
> Mike Champion writes:
> > The case for alternative serializations really couldn't have been
> > plausibly made until very recently. Now there are all sorts of
> > people who want to author in WikiML or whatever, parse thousands of
> > messages a minute, send XML to wristwatches, etc.
>
> First, someone needs to establish what the extra overhead of XML over
> binary formats (bandwidth and processing time) actually is in
> realistic use cases.
Please describe what a "realistic use case" is to you, and time allowing I'll be
happy to oblige. I'd also be glad to know what in the use cases that have
already been cited many times in this permathread is not realistic.
> If we're dealing with wristwatches that display
> images or even video, for example, then relatively speaking any text
> format (including XML) represents a negligable bandwidth and storage
> hit.
I don't know about wristwatches that display video, but I know about the tiny
devices and about video situations. For tiny devices (less powerful than your
typical cell phone) storage can be a problem and so can parsing time (on the
smaller ones, eg digital radios).
For video, parsing is usually not a problem (though people are always happy to
save cycles there) but bandwidth *really* is (and I won't go into streamability
issues). I don't know what amount of XML you had in mind but for those that are
typically found in broadcast/digital TV/digital radio, there certainly is no
sufficient bandwidth. Real-time video metadata, captionning, TV programs,
personalised services, etc all consume a fair amount of bandwidth if they are to
be expressed as XML. And the problem is worsened by the fact that it is a
unidirectional environment, so that the information has to be continously broadcast.
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway http://expway.fr/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
