Lists Home |
Date Index |
Wolfgang Hoschek wrote:
> On Feb 9, 2005, at 1:17 PM, Rick Marshall wrote:
>> even it's own documentation says this is not a binary xml format (at
>> least that we can rely on) because the authors reserve the right to
>> change it at will and warn against storing a bnux transformed
>> document because it may not be able to be decoded in the future.
>> how many xml principles does this break? perhaps it could be question
>> of the week :)
>> worse - the encoder/decoder must therefore be deployed in pairs - and
>> upgraded in pairs. this may later become the basis of something, but
>> it is along way from being a binary xml coding that is useful in
> That's because binary XML makes most sense in tightly coupled systems
> (and the intended usage is clearly stated as such - there's no
> ambiguity here).
this doesn't answer the question of how to upgrade a million phones
because a newer, better serialisation has been worked out. in fact that
in general is the problem with all widely deployed technologies - how
many websites still consider supporting netscape4?
bnux seems to me to be a useful inhouse protocol, but not a general,
standardised, industry solution.
>> and finally if gzip/zip type compressions can add even more - why not
>> just use them and put the effort into more efficient gzip algorithms
>> - or better still a gzip encoder/decoder chip :) for use in mobile
>> phones etc.
> Better compression does not necessarily equal better performance. GZIP
> is very compute-intensive, it actually degrades performance (while it
> does offer more compression). You can verify this yourself via the
> compressionLevel flag. There's an explicit tradeoff here to be made.
tel;cell:+61 411 287 530