We have just been forced to refactor/recode a significant
portion of one of our AIR based RIA's due to an arbitrary decision
made by the Webkit team to restrict all XML HTTP requests via a
hard coded, hidden timeout of 60 seconds. This decision not only
affects AIR but also affects Safari and other browsers based upon
Our application performs complex analytic queries which may
run to a few minutes. Whilst long synchronous requests are not
generally a good idea for web based solutions, we believe that RIA
intranet applications are a completely different ball game and
should not be subject to arbitrary constraints such as these with
no flexibility or warning. We would not see this behaviour in Java
/ C# or other such application languages, so why are we seeing this
in Adobe AIR?
Our MD has understandably questioned the suitability of Adobe
AIR for future developments of enterprise RIA's, and we are all
naturally concerned about other "features" being added or removed
to the Adobe AIR functionality, even indirectly and whether in fact
we can rely upon Adobe to monitor the stability of their runtime.
We don't believe it is acceptable for us to tell our customers that
it was the fault of a component nested within multiple layers of
the runtime outside of our control and believe that it is equally
unacceptable for Adobe to stand by and claim the same.
We are excited about the prospects of investing in Adobe AIR
for delivering rapid RIAs to our customers, but are we to expect
similar show stoppers to arise over the coming months or even
years, and can we trust the Adobe runtime as an "In production"
solution going forward.
Thanks for bringing this to our attention. We, as I'm sure
you realize, aren't claiming that this sort of thing is ok. And we
do work hard to maintain the stability of the runtime. However, it
can be difficult to know a priori everything that we need to keep
an eye on. That's one of the reasons we have forums like this one
and we very much appreciate this kind of feedback.
As for this particular issue, I'll just point out that you
might consider taking advantage of the flash.net.* APIs to manage
your network request, at least as a temporary workaround.