We recently added a new AIR 2.0 API which didn’t make it into my MAX presentation:
URLRequest.idleTimeoutURLRequestDefaults.idleTimeout
These setters specify the amount of time (in milliseconds) that a connection will remain open before receiving any data. Certainly not as sexy as some of our other new features (native processes, file promises, multi-touch, accessibility, volume detection, socket servers, etc.), but if you’re trying to use long polling, you’ll probably find this API useful.

And what about this one?http://bugs.adobe.com/jira/browse/FP-6Socket servers will be quite useless if AIR2.0 did not get this feature.
We are looking at the possibility of implementing a PROGRESS_EVENT on Sockets, but I don’t think it will make it into AIR 2.0. We’re also looking at some other improvements around how data is written to sockets. Hopefully we’ll get these features in soon after 2.0.Christian
I agree with maliboo. Such things are involuntarily hampering Adobe Air’s acceptance as a development Platform of choice.
Christian,
Does setting this value affect the timeout of RemoteObjects? I’m still seeing RemoteObject timeouts when running AIR applications on Windows and it’s kind of a show stopper if I can’t address it.
Jeff