You've still managed to avoid telling us about your back-end setup.
Tell us more about that and we could probably be of more assistance.
No good me suggesting stuff that works for apache on linux to find
that you're running openVMS...
On 06/03/2009, at 4:12 PM, David Adams wrote:
On Fri, Mar 6, 2009 at 11:55 AM, Guy Morton <g...@alchemy.com.au>
wrote:
> JSON isn't binary but is more compact than XML. OTOH, parsing it
may not be
> as quick as XML.
I haven't tested it yet in the Flash player but the post I linked to
earlier claimed String.split (native to the player) is considerably
faster than the native XML parser - at least in some cases. That's not
hard to imagine, really. Either JSON or XML are text - both of which
should benefit - even quite dramatically - from compression.
> I wouldn't be manually zipping and unzipping data - a better idea
would be
> to enable GZIP on the web server and let the browser do the work
(not that
> that is trouble-free but still...).
That sounds great and I'd like to pursue this as a few other people
have made the same observation. In my tests, the gzipping wasn't
happing in the browser prior to the data being loaded into the Flash
player. I set the MIME type on the server to "application/gzip" or
similar (I looked up the correct-sounding type at the time.)
Can anyone point me to a working example of gzipping working
'passively' but effectively? Namely, that the Flash player gets
uncompressed data even though the server sends the data compressed.
That would be ideal.
> Here:
http://www.jamesward.com/blog/2007/12/12/blazebench-why-you-want-amf-and-blazeds/
> That should help you see what combinations are fast.
Thanks - it's a great article. The author mentions gzipping but I
haven't found the specifics. I suspect he's comparing processes
without any compression.
