Re: [xml-dev] JavaScript (was Re: [xml-dev] Whither XML ?)

[David <dlee@calldei.com>]

This is getting WAY off topic, but I'll answer quickly, and if anyone is 
further interested send me private mail.

Devices that don't support content-encoding gzip that I *know of*
Palm (legacy, all versions)
Windows Mobile

Blackberry (sorta ... there is a limit to the size of a single HTTP 
request on some BB networks, the network itself imposes it, its 
somewhere around 100k.  I havent personally tested gzip CE, but I have 
hit the brick wall of large transfer limits.
You have to manually split up the transfer, HTTP1.1 chunking doesn't do 
it because your socket is terminated.


I'm not 100% sure about the palm WebOS,
iPhone and Android to my knowledge *do* support gzip CE.

But thats just the tip of the iceburg.   Reliably sending large amounts 
of data (say > 100k) to any mobile device is difficult.
Networks just drop connections or hang at whims even when stationary in 
good areas.  So its not just "turn on gzip, problem solved".




David A. Lee
dlee@calldei.com
http://www.xmlsh.org


On 11/11/2010 11:39 AM, Julian Reschke wrote:
>
> Hi David,
>
> Understood. I can see the problem with binary in general; I just 
> wanted to point that sending XML in an efficient way *should* be 
> possible already.
>
> Which devices do not understand C-E: gzip?
>
> Best regards, Julian
>
> On 11.11.2010 17:28, David wrote:
>> Some devices do support gzip HTTP encoding of text data some don't.
>> Even the ones that do, doesn't solve the problem of wanting to send
>> binary data which is not simply gzip'd text using JS.
>> Javascript doesnt have a binary type, the JS HTTP API's dont allow you
>> to fetch (into a JS variable) a binary result from an HTTP request.
>> (except that interesting hack with PNG images ... )
>>
>> And even if you do get gzip'd text the in-memory footprint of such text
>> is big, due to 16 bit chars
>> and processing said text byte by byte in JS is inefficient.
>>
>> For us who've gotten fat & lazy with the good life of pretending
>> everyone has 4G of ram and a 4Ghz quad core processor, working on mobile
>> devices is humbling. Even when those devices are 100x more powerful of
>> the PC's of yesteryear.
>> Add JavaScript to the mix and the dissertation that it is "The VM of the
>> Browser", then add the architectural concept that every app should be a
>> locally running "web app" (Web/OS style) and life is a sad sad state of
>> affairs.
>>
>> I'm sorry but I just dont buy it. Until JS improves *dramatically* (not
>> just in speed but capibility) I predict we will NOT see the plethra of
>> high quality 'web apps' that pendants predict. You just need to look at
>> your iPhone for proof.
>> You can run web apps on it, you can run native apps. How many '100% pure
>> web apps' on the iphone are worth using ?
>> Do you launch a browser and go to maps.google.com ? or do you launch the
>> Google Maps native app.
>>
>> Why ?
>>
>>
>>
>> David A. Lee
>> dlee@calldei.com
>> http://www.xmlsh.org
>>
>>>>
>>>>
>>>> We were completely unable to adopt this technique to the Palm 
>>>> Web/OS due
>>>> to the inability to do binary IO and efficient binary parsing.
>>>> ...
>>>
>>> Are you saying those do not support
>>>
>>> Content-Encoding: gzip
>>>
>>> ?
>>>
>>> Best regards, Julian
>>