How to Test AIR 1.5

Tom, I am not sure, given the lengthy thread here and my rather poor descriptions of the parts of the Flex and AIR apis with which I am concerned, whether or not I completely understand what sort of details you are seeking in quoting the portion of my last posting that you did. If there is a way to take this up off-line, I think everyone would rather I did that, but I don't see where/how this particular forum supports private messages so I will try to be brief.

01. My view of an AIR application is one that does, of course, support some functionality which behaves quite nicely detached from the Internet, but does require Internet access for some functionality as well as for the important steps of initial provisioning and periodic update.
02. Just to take the use case of some functionality -- outside of provisioning and periodic update, which is the real matter I was addressing in this posting -- my user's can 'blow into the microphone' to perturb the on-going actions of a simulation that uses the Actionscript Physics Engine [APE]. To do that, my code must successfully exchange packets with an Adobe server that is keeping track of the user's security. That is what I meant when I said that there was already a dependency, so I don't think adding a new dependency -- for nice support of framework version management -- causes any problem.
03. With that background/clarification, if your question is about the bug I reported with the 1.5 release, it manifests itself when I attempt to use SWFLoader to load a Flex-based sub-applciation into an AIR-based main application AND have compiled the Flex-based application for dynamic linking with respect to the Flex framework. If you are not concerned with such an application architecture, you should not see the error. In particular, if you do have Flex-based sub-applications being managed by an AIR application, but you are willing to incur the overhead of compilation for static linkage [which is probably the use case for most folks, as others have observed], the problem would not arise.
04. If your concerns do fall in the latter, minority case, all I can pass along is that I have not been able to see how a user can make method calls using the LoaderUtils class to solve the problem. The currently-failing error in which one url is separated from another url with the string 'DYNAMIC' is produced as an artifact of an attempt to load that occurs in some code outside of api access, so I am waiting for the fix that Matt says will be coming before I try again.
I hope that helps.

On Tuesday 25 Nov 2008, Terry Corbet wrote:
> We have to rely on your servers for Security anyway, so there is already a
> built-in co-dependence between what any developer develops and what you are
> supporting.

Could you post some details on that ?
In particular, I'd like to know the failure mode, because not all devices are
online and it's also not unknown for a new product release to kill
adobe.com...

--
Tom Chiverton
Helping to greatly benchmark granular information



****************************************************

This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500.

For more information about Halliwells LLP visit www.halliwells.com.

Matt,

I'm sure I can speak for most of the community when I say that you guys are doing a great job of balancing Adobe's needs with those of the open-source Flex community, and we all appreciate the openness, communication and honesty we get from the team. A pleasant change from the committee-obsessed Sun, and the less said about Microsoft's community attitude the better ;-)


Cheers,
-Josh




--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

Like the cut of my jib? Check out my Flex blog!

:: Josh 'G-Funk' McDonald

:: 0437 221 380 :: josh@gfunk007.com
:: http://flex.joshmcdonald.info/
:: http://twitter.com/sophistifunk

Framework on our servers is something we're looking into for Gumbo. As for documentation on doing modularization with AIR, you're probably right that we could provide more. I admit to not prioritizing the download size of AIR apps very high compared to the web experience.<br /><br />Something we can look into in the future.<br /><br />Matt<br /><br />On 11/25/08 12:43 PM, "Terry Corbet" <member@adobeforums.com> wrote:<br /><br />A new message was posted by Terry Corbet in<br /><br />Developers --<br /> How to Test AIR 1.5<br /><br />Thanks for both replies. I will try to see if I understand LoaderUtils well<br />enough to at least learn what caused the failure. I can wait for the fix,<br />but what I most have really been trying to get in response to my flailing<br />about is some sort of 'best practices' paper talking about the basic issue.<br />With the Nov 17 roll out, I see a huge effort put into the PDF discussing<br />"Loading Sub-Applications", but, as with security white papers and other<br />documents about 'modularization', whenever the author needs adopt his<br />comments/recommendations to AIR, it is like the sentence falls off the end<br />of the earth. "Oh, yes, this doesn't quite apply to AIR."<br /><br />What does apply to AIR? We need a definitive statement concerning caching<br />of Adobe frameworks when talking about AIR.<br /><br />Beyond that, somewhere along the way I submitted a suggestion for<br />enhancement that included the idea that in both environments -- Flex or<br />AIR -- the URL to which we would really like to point when it comes time to<br />access the .swz files, is one on your servers. Even if you are dealing with<br />the complexities of 'sub-applications' that require access to several<br />versions of the same framework files -- or maybe especially if you are<br />dealing with the complexities of 'sub-applications' that require access to<br />several versions of the same framework files -- the best place to host those<br />download requests is at Adobe.<br /><br />We have to rely on your servers for Security anyway, so there is already a<br />built-in co-dependence between what any developer develops and what you are<br />supporting. Putting the framework on an Adobe server and letting the AIR<br />runtime and the Player 'go there' whenever it sees that it is about to load<br />a 'chunk of code' that was compiled for dynamic linkage, would just make the<br />cross-over from Flex to AIR almost transparent. Right now that whole topic<br />is so opaque that I am sure there are not 10 people who are trying to take<br />advantage of the framework cache from an AIR application.<br /><br />Thanks again -- both Flex and AIR are superb facilities, but those Redmond<br />guys still have a lot of clout and we have to do everything possible to stay<br />in front of that pack.<br /><br />----- Original Message -----<br />From: "Matt Chotin" <member@adobeforums.com><br />To: <flexsdk-dev@adobeforums.com><br />Sent: Tuesday, November 25, 2008 8:45 AM<br />Subject: Re: How to Test AIR 1.5<br /><br /><br />>A new message was posted by Matt Chotin in<br />><br />> Developers --<br />> How to Test AIR 1.5<br />><br />> Oh, and it's something you could probably patch yourself by looking at how<br />> LoaderUtils works if you don't want to wait.<br />><br />><br />> On 11/18/08 5:22 PM, "Terry Corbet" <member@adobeforums.com> wrote:<br />><br />> A new message was posted by Terry Corbet in<br />><br />> Developers --<br />> How to Test AIR 1.5<br />><br />> 01. OK, thanks for keeping the promise of something to work with in a<br />> couple of weeks. I downloaded the 3.2.0.3958 source last Friday and<br />> started some more aggressive testing. I did not see any official<br />> announcement of the availability of the 1.5 runtime, but at least the<br />> spate of releases yesterday, spurred some other network traffic that<br />> resulted in my becoming aware that I could get that piece of the puzzle to<br />> go along with the adt code.<br />><br />> 02. So, now with another full day of testing, I think I can state my<br />> problem, but I don't seem to be able to find the forum or format that will<br />> get the message I think needs to be sent. So, here's just a parable that<br />> should sum it up.<br />><br />> A. I write five killer Flex applications.<br />> B. I compile them all with dynamic linkage to the Flex framework for the<br />> obvious of advantage of NOT asking my users to download an average of<br />> about an additional quarter megabyte each time. Caching of the framework<br />> [let's ignore the possibilities of their being at different release<br />> levels, just to keep this simple] even if my users don't happen to have<br />> other Flex applications from other sources, is just plain smart in this<br />> use case.<br />> C. Now, I create a shell using the AIR platform, and take advantage of<br />> some of the AIR-special facilities, but basically, all I want to do is<br />> give my users access to the same, original five Flex applications in a<br />> more convenient manner. Let's just say that 'provisioning the desktop'<br />> via one integrated AIR window, is in some ways nicer than 'provisioning<br />> that desktop' via the five independent browser windows.<br />> D. So, with the previous SDK releases [even when switching from Player 9<br />> to Player 10] on the user's systems, I could continue to use the<br />> dynamically-linked .swf files for the five Flex-based applications via a<br />> SWFloader in the AIR shell. Obviously, this savings of a quarter of a<br />> megabyte times five, was the smart thing to do.<br />> E. With the 3.2.0.3958 release, the Runtime [or the Runtime's interaction<br />> with the Player, I have no idea what that internal architecture looks<br />> like, since you don't document or disclose it] will no longer work that<br />> nice way. Now I am required to link the five Flex-based applications<br />> statically and incur the five times a quarter of a megabyte overhead when<br />> provisioning my users' desktop.<br />><br />> 03. Who do I send this to in order to get someone to step back and<br />> re-think why it is that you [the collective you] seem to think that the<br />> planning and execution of a modularized application in AIR should not take<br />> advantage of precisely the same, sensible caching that is built in when<br />> the application is just plain old Flex?<br />><br />> You can tell me that AIR is going to be able to use the Player 10 graphics<br />> primitives to stand on its head and sing in Swahili, but you have just<br />> devalued AIR with these changes. Sex appeal won't make up for solid<br />> systems engineering of large applicati! ons. I am certain no one wants to<br />> devalue AIR but just follow the parable of five applications out to a<br />> dozen or more and look how wasteful the AIR solution becomes. In the<br />> meantime, folks just staying with Flex and ignoring AIR will watch as that<br />> runtime library of cacheable infrastructure grows and matures.<br />><br />> ________________________________<br />> View/reply at How to Test AIR 1.5<br />> <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/8><br />> Replies by email are OK.<br />> Use the unsubscribe<br />> <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to<br />> cancel your email subscription.<br />><br />><br />><br />><br />> ------------------------------------------------------<br />> View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/10><br />> Replies by email are OK.<br />> Use the unsubscribe form at<br />> <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to<br />> cancel your email subscription.<br /><br /><br /><br />------------------------------------------------------<br />View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/11><br />Replies by email are OK.<br />Use the unsubscribe form at <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.

Thanks for both replies. I will try to see if I understand LoaderUtils well <br />enough to at least learn what caused the failure. I can wait for the fix, <br />but what I most have really been trying to get in response to my flailing <br />about is some sort of 'best practices' paper talking about the basic issue. <br />With the Nov 17 roll out, I see a huge effort put into the PDF discussing <br />"Loading Sub-Applications", but, as with security white papers and other <br />documents about 'modularization', whenever the author needs adopt his <br />comments/recommendations to AIR, it is like the sentence falls off the end <br />of the earth. "Oh, yes, this doesn't quite apply to AIR."<br /><br />What does apply to AIR? We need a definitive statement concerning caching <br />of Adobe frameworks when talking about AIR.<br /><br />Beyond that, somewhere along the way I submitted a suggestion for <br />enhancement that included the idea that in both environments -- Flex or <br />AIR -- the URL to which we would really like to point when it comes time to <br />access the .swz files, is one on your servers. Even if you are dealing with <br />the complexities of 'sub-applications' that require access to several <br />versions of the same framework files -- or maybe especially if you are <br />dealing with the complexities of 'sub-applications' that require access to <br />several versions of the same framework files -- the best place to host those <br />download requests is at Adobe.<br /><br />We have to rely on your servers for Security anyway, so there is already a <br />built-in co-dependence between what any developer develops and what you are <br />supporting. Putting the framework on an Adobe server and letting the AIR <br />runtime and the Player 'go there' whenever it sees that it is about to load <br />a 'chunk of code' that was compiled for dynamic linkage, would just make the <br />cross-over from Flex to AIR almost transparent. Right now that whole topic <br />is so opaque that I am sure there are not 10 people who are trying to take <br />advantage of the framework cache from an AIR application.<br /><br />Thanks again -- both Flex and AIR are superb facilities, but those Redmond <br />guys still have a lot of clout and we have to do everything possible to stay <br />in front of that pack.<br /><br />----- Original Message ----- <br />From: "Matt Chotin" <member@adobeforums.com><br />To: <flexsdk-dev@adobeforums.com><br />Sent: Tuesday, November 25, 2008 8:45 AM<br />Subject: Re: How to Test AIR 1.5<br /><br /><br />>A new message was posted by Matt Chotin in<br />><br />> Developers --<br />> How to Test AIR 1.5<br />><br />> Oh, and it's something you could probably patch yourself by looking at how <br />> LoaderUtils works if you don't want to wait.<br />><br />><br />> On 11/18/08 5:22 PM, "Terry Corbet" <member@adobeforums.com> wrote:<br />><br />> A new message was posted by Terry Corbet in<br />><br />> Developers --<br />> How to Test AIR 1.5<br />><br />> 01. OK, thanks for keeping the promise of something to work with in a <br />> couple of weeks. I downloaded the 3.2.0.3958 source last Friday and <br />> started some more aggressive testing. I did not see any official <br />> announcement of the availability of the 1.5 runtime, but at least the <br />> spate of releases yesterday, spurred some other network traffic that <br />> resulted in my becoming aware that I could get that piece of the puzzle to <br />> go along with the adt code.<br />><br />> 02. So, now with another full day of testing, I think I can state my <br />> problem, but I don't seem to be able to find the forum or format that will <br />> get the message I think needs to be sent. So, here's just a parable that <br />> should sum it up.<br />><br />> A. I write five killer Flex applications.<br />> B. I compile them all with dynamic linkage to the Flex framework for the <br />> obvious of advantage of NOT asking my users to download an average of <br />> about an additional quarter megabyte each time. Caching of the framework <br />> [let's ignore the possibilities of their being at different release <br />> levels, just to keep this simple] even if my users don't happen to have <br />> other Flex applications from other sources, is just plain smart in this <br />> use case.<br />> C. Now, I create a shell using the AIR platform, and take advantage of <br />> some of the AIR-special facilities, but basically, all I want to do is <br />> give my users access to the same, original five Flex applications in a <br />> more convenient manner. Let's just say that 'provisioning the desktop' <br />> via one integrated AIR window, is in some ways nicer than 'provisioning <br />> that desktop' via the five independent browser windows.<br />> D. So, with the previous SDK releases [even when switching from Player 9 <br />> to Player 10] on the user's systems, I could continue to use the <br />> dynamically-linked .swf files for the five Flex-based applications via a <br />> SWFloader in the AIR shell. Obviously, this savings of a quarter of a <br />> megabyte times five, was the smart thing to do.<br />> E. With the 3.2.0.3958 release, the Runtime [or the Runtime's interaction <br />> with the Player, I have no idea what that internal architecture looks <br />> like, since you don't document or disclose it] will no longer work that <br />> nice way. Now I am required to link the five Flex-based applications <br />> statically and incur the five times a quarter of a megabyte overhead when <br />> provisioning my users' desktop.<br />><br />> 03. Who do I send this to in order to get someone to step back and <br />> re-think why it is that you [the collective you] seem to think that the <br />> planning and execution of a modularized application in AIR should not take <br />> advantage of precisely the same, sensible caching that is built in when <br />> the application is just plain old Flex?<br />><br />> You can tell me that AIR is going to be able to use the Player 10 graphics <br />> primitives to stand on its head and sing in Swahili, but you have just <br />> devalued AIR with these changes. Sex appeal won't make up for solid <br />> systems engineering of large applicati! ons. I am certain no one wants to <br />> devalue AIR but just follow the parable of five applications out to a <br />> dozen or more and look how wasteful the AIR solution becomes. In the <br />> meantime, folks just staying with Flex and ignoring AIR will watch as that <br />> runtime library of cacheable infrastructure grows and matures.<br />><br />> ________________________________<br />> View/reply at How to Test AIR 1.5 <br />> <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/8><br />> Replies by email are OK.<br />> Use the unsubscribe <br />> <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to <br />> cancel your email subscription.<br />><br />><br />><br />><br />> ------------------------------------------------------<br />> View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/10><br />> Replies by email are OK.<br />> Use the unsubscribe form at <br />> <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to <br />> cancel your email subscription.

Oh, and it's something you could probably patch yourself by looking at how LoaderUtils works if you don't want to wait.<br /><br /><br />On 11/18/08 5:22 PM, "Terry Corbet" <member@adobeforums.com> wrote:<br /><br />A new message was posted by Terry Corbet in<br /><br />Developers --<br /> How to Test AIR 1.5<br /><br />01. OK, thanks for keeping the promise of something to work with in a couple of weeks. I downloaded the 3.2.0.3958 source last Friday and started some more aggressive testing. I did not see any official announcement of the availability of the 1.5 runtime, but at least the spate of releases yesterday, spurred some other network traffic that resulted in my becoming aware that I could get that piece of the puzzle to go along with the adt code.<br /><br />02. So, now with another full day of testing, I think I can state my problem, but I don't seem to be able to find the forum or format that will get the message I think needs to be sent. So, here's just a parable that should sum it up.<br /><br />A. I write five killer Flex applications.<br />B. I compile them all with dynamic linkage to the Flex framework for the obvious of advantage of NOT asking my users to download an average of about an additional quarter megabyte each time. Caching of the framework [let's ignore the possibilities of their being at different release levels, just to keep this simple] even if my users don't happen to have other Flex applications from other sources, is just plain smart in this use case.<br />C. Now, I create a shell using the AIR platform, and take advantage of some of the AIR-special facilities, but basically, all I want to do is give my users access to the same, original five Flex applications in a more convenient manner. Let's just say that 'provisioning the desktop' via one integrated AIR window, is in some ways nicer than 'provisioning that desktop' via the five independent browser windows.<br />D. So, with the previous SDK releases [even when switching from Player 9 to Player 10] on the user's systems, I could continue to use the dynamically-linked .swf files for the five Flex-based applications via a SWFloader in the AIR shell. Obviously, this savings of a quarter of a megabyte times five, was the smart thing to do.<br />E. With the 3.2.0.3958 release, the Runtime [or the Runtime's interaction with the Player, I have no idea what that internal architecture looks like, since you don't document or disclose it] will no longer work that nice way. Now I am required to link the five Flex-based applications statically and incur the five times a quarter of a megabyte overhead when provisioning my users' desktop.<br /><br />03. Who do I send this to in order to get someone to step back and re-think why it is that you [the collective you] seem to think that the planning and execution of a modularized application in AIR should not take advantage of precisely the same, sensible caching that is built in when the application is just plain old Flex?<br /><br />You can tell me that AIR is going to be able to use the Player 10 graphics primitives to stand on its head and sing in Swahili, but you have just devalued AIR with these changes. Sex appeal won't make up for solid systems engineering of large applicati! ons. I am certain no one wants to devalue AIR but just follow the parable of five applications out to a dozen or more and look how wasteful the AIR solution becomes. In the meantime, folks just staying with Flex and ignoring AIR will watch as that runtime library of cacheable infrastructure grows and matures.<br /><br />________________________________<br />View/reply at How to Test AIR 1.5 <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/8><br />Replies by email are OK.<br />Use the unsubscribe <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to cancel your email subscription.

Hi Terry,<br /><br />The engineers looked and realized we broke how RSLs are loaded using relative urls. You can either hard-code the path of the RSL for now, or we should have a nightly build in a bit (maybe next week) that has the problem addressed.<br /><br />Matt<br /><br /><br />On 11/18/08 5:22 PM, "Terry Corbet" <member@adobeforums.com> wrote:<br /><br />A new message was posted by Terry Corbet in<br /><br />Developers --<br /> How to Test AIR 1.5<br /><br />01. OK, thanks for keeping the promise of something to work with in a couple of weeks. I downloaded the 3.2.0.3958 source last Friday and started some more aggressive testing. I did not see any official announcement of the availability of the 1.5 runtime, but at least the spate of releases yesterday, spurred some other network traffic that resulted in my becoming aware that I could get that piece of the puzzle to go along with the adt code.<br /><br />02. So, now with another full day of testing, I think I can state my problem, but I don't seem to be able to find the forum or format that will get the message I think needs to be sent. So, here's just a parable that should sum it up.<br /><br />A. I write five killer Flex applications.<br />B. I compile them all with dynamic linkage to the Flex framework for the obvious of advantage of NOT asking my users to download an average of about an additional quarter megabyte each time. Caching of the framework [let's ignore the possibilities of their being at different release levels, just to keep this simple] even if my users don't happen to have other Flex applications from other sources, is just plain smart in this use case.<br />C. Now, I create a shell using the AIR platform, and take advantage of some of the AIR-special facilities, but basically, all I want to do is give my users access to the same, original five Flex applications in a more convenient manner. Let's just say that 'provisioning the desktop' via one integrated AIR window, is in some ways nicer than 'provisioning that desktop' via the five independent browser windows.<br />D. So, with the previous SDK releases [even when switching from Player 9 to Player 10] on the user's systems, I could continue to use the dynamically-linked .swf files for the five Flex-based applications via a SWFloader in the AIR shell. Obviously, this savings of a quarter of a megabyte times five, was the smart thing to do.<br />E. With the 3.2.0.3958 release, the Runtime [or the Runtime's interaction with the Player, I have no idea what that internal architecture looks like, since you don't document or disclose it] will no longer work that nice way. Now I am required to link the five Flex-based applications statically and incur the five times a quarter of a megabyte overhead when provisioning my users' desktop.<br /><br />03. Who do I send this to in order to get someone to step back and re-think why it is that you [the collective you] seem to think that the planning and execution of a modularized application in AIR should not take advantage of precisely the same, sensible caching that is built in when the application is just plain old Flex?<br /><br />You can tell me that AIR is going to be able to use the Player 10 graphics primitives to stand on its head and sing in Swahili, but you have just devalued AIR with these changes. Sex appeal won't make up for solid systems engineering of large applicati! ons. I am certain no one wants to devalue AIR but just follow the parable of five applications out to a dozen or more and look how wasteful the AIR solution becomes. In the meantime, folks just staying with Flex and ignoring AIR will watch as that runtime library of cacheable infrastructure grows and matures.<br /><br />________________________________<br />View/reply at How to Test AIR 1.5 <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/8><br />Replies by email are OK.<br />Use the unsubscribe <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to cancel your email subscription.

01. OK, thanks for keeping the promise of something to work with in a couple of weeks. I downloaded the 3.2.0.3958 source last Friday and started some more aggressive testing. I did not see any official announcement of the availability of the 1.5 runtime, but at least the spate of releases yesterday, spurred some other network traffic that resulted in my becoming aware that I could get that piece of the puzzle to go along with the adt code.

02. So, now with another full day of testing, I think I can state my problem, but I don't seem to be able to find the forum or format that will get the message I think needs to be sent. So, here's just a parable that should sum it up.

A. I write five killer Flex applications.
B. I compile them all with dynamic linkage to the Flex framework for the obvious of advantage of NOT asking my users to download an average of about an additional quarter megabyte each time. Caching of the framework [let's ignore the possibilities of their being at different release levels, just to keep this simple] even if my users don't happen to have other Flex applications from other sources, is just plain smart in this use case.
C. Now, I create a shell using the AIR platform, and take advantage of some of the AIR-special facilities, but basically, all I want to do is give my users access to the same, original five Flex applications in a more convenient manner. Let's just say that 'provisioning the desktop' via one integrated AIR window, is in some ways nicer than 'provisioning that desktop' via the five independent browser windows.
D. So, with the previous SDK releases [even when switching from Player 9 to Player 10] on the user's systems, I could continue to use the dynamically-linked .swf files for the five Flex-based applications via a SWFloader in the AIR shell. Obviously, this savings of a quarter of a megabyte times five, was the smart thing to do.
E. With the 3.2.0.3958 release, the Runtime [or the Runtime's interaction with the Player, I have no idea what that internal architecture looks like, since you don't document or disclose it] will no longer work that nice way. Now I am required to link the five Flex-based applications statically and incur the five times a quarter of a megabyte overhead when provisioning my users' desktop.

03. Who do I send this to in order to get someone to step back and re-think why it is that you [the collective you] seem to think that the planning and execution of a modularized application in AIR should not take advantage of precisely the same, sensible caching that is built in when the application is just plain old Flex?

You can tell me that AIR is going to be able to use the Player 10 graphics primitives to stand on its head and sing in Swahili, but you have just devalued AIR with these changes. Sex appeal won't make up for solid systems engineering of large applications. I am certain no one wants to devalue AIR but just follow the parable of five applications out to a dozen or more and look how wasteful the AIR solution becomes. In the meantime, folks just staying with Flex and ignoring AIR will watch as that runtime library of cacheable infrastructure grows and matures.

Without more details about how they aren't working, I'm going to take<br />a stab and guess that it might be the same issue I ran across<br />recently. I was getting the error "ArgumentError: Error #2005:<br />Parameter 0 is of the incorrect type. Should be type Filter.". The<br />syntax for applying filters changed slightly. Full details are at:<br />https://bugs.adobe.com/jira/browse/SDK-17964<br /><br />-- Daniel R. <danielr@neophi.com> [http://danielr.neophi.com/]<br /><br />On Sun, Nov 9, 2008 at 5:00 AM, Pradeek <member@adobeforums.com> wrote:<br />> A new message was posted by Pradeek in<br />><br />> Developers --<br />> How to Test AIR 1.5<br />><br />> I'm using the Gumbo builds and pixel blnder filters aren't workng in AIR 1.5

I'm using the Gumbo builds and pixel blnder filters aren't workng in AIR 1.5