[
Lists Home |
Date Index |
Thread 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
>> general.
>
>
> 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.
rick
>>
>> 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.
>
>
> !DSPAM:420a88175891215416753!
>
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
