Not supported: Air + Ajax + (flex-ajax-bridge) + LCDS

Question

I'm building an application Air (Flex + extjs) and offline synchronization with LCDS. For sure I need the flex-ajax-bridge.
But the experiments failed on Air runtime container, when ajax tried to communicate with server end data services.
And I checked the source code of flex bridge file (FDMSBridge.as):
import bridge.FABridge;
import flash.display.DisplayObject;
import flash.display.MovieClip;
import flash.events.Event;
import flash.external.ExternalInterface;
import mx.core.mx_internal;
use namespace object_proxy;
[Frame(extraClass="FakeFlexInit")]
public class FDMSBridge extends FDMSBase
private var gateway:FABridge;
public function FDMSBridge()
super();
if (ExternalInterface.available == false)
return;
ExternalInterface.addCallback("createObject", createObject);
private function createObject(className:String, cArgs:Array):Object
From the source code, we can tell the bridge rely heavily on the flash.external interface; AND look at this link -
http://livedocs.adobe.com/labs/air/1/aslr/flash/external/ExternalInterface.html
where it says -
Note: Adobe AIR currently does not support the ExternalInterface class.
which leads to the conclusion that:
Air + Ajax(HTML) + LCDS solution is not supported by AIR currently.
The ExternalInterface class environment:
Browser Operating System Operating System
Internet Explorer 5.0 and later Windows
Netscape 8.0 and later Windows MacOS
Mozilla 1.7.5 and later Windows MacOS
Firefox 1.0 and later Windows MacOS
Safari 1.3 and later MacOS
Can anyone tell me what's the version of AIR built-in browser (squirralfish)? or, will AIR support FDMSBridge soon?
Thanks!

Answer 1

I agree, it would be nice to have gzip encoding support in
AIR's browser component. But, I looked at what my AIR app sends
when it requests a web page, and it's not claiming to the remote
server that it can support gzip. If the server is sending the
content gzipped anyway, it's almost certainly broken. Web servers
aren't supposed to dictate encodings. Clients say what they're
capable of receiving, and servers send the data in that format if
they're capable of sending any of the requested formats.
I see only one exception in the spec.
Section
14.3 says the server is allowed to send what it likes if the
client doesn't say what it wants (true for AIR) and it cannot
support the default, which is to say, sending the raw data as it is
on disk. So, is that the case? Can this server really not send raw
data, to anyone, ever? If so, it's violating the spirit of the web,
to the point that I'd say it's broken, even if the spec does allow
it. And if the server really is capable of sending the raw data,
it's
really broken for insisting on sending it compressed when
the client hasn't told it that it can handle it; this would
actually be against the spec, not just against the spirit of the
spec.
It would seem a more sensible use of your time to fix the
server than to go and learn another technology just to work around
its brokenness.