How to Test AIR 1.5

Report · Nov 03, 2008

Sorry if this seems slightly off center, but I blame Adobe, not myself. Trying to determine the true status and positioning of AIR amongst the various Flex forums and projects for an outsider is practically impossible. So, I will be brief. In September Mr. Chambers sent opened the flow by telling us that we could find FP10 integrated with Flex SDK in something you call 1.5 or Cosmo, or both. He was properly circumspect, so I didn't rush into it -- there was not even an ADL binary when I checked. Now it is November, the Trunk is at 4005, and ostensibly, everything we need to start trying to take advantage of FP support of 3D operations is out there. But where? Where do we get a version of AIR 1.5 that can be installed on a target desktop, so that we can try to run the ADT test cycle?

Call it Gumbo, call it Flex4, call it whatever, but can someone tell us how to start testing it for AIR application deployment?

Thank you.

Report · Nov 03, 2008

Hi, We're not doing a public beta of the release runtime for AIR 1.5. You can use the debug runtimes that are part of the Flex nightly builds though (check the Flex 3 nightlies) to validate that AIR 1.5 will be right for you though. Matt On 11/3/08 7:38 PM, "Terry Corbet" <member@adobeforums.com> wrote: A new discussion was started by Terry Corbet in Developers -- How to Test AIR 1.5 Sorry if this seems slightly off center, but I blame Adobe, not myself. Trying to determine the true status and positioning of AIR amongst the various Flex forums and projects for an outsider is practically impossible. So, I will be brief. In September Mr. Chambers sent opened the flow by telling us that we could find FP10 integrated with Flex SDK in something you call 1.5 or Cosmo, or both. He was properly circumspect, so I didn't rush into it -- there was not even an ADL binary when I checked. Now it is November, the Trunk is at 4005, and ostensibly, everything we need to start trying to take advantage of FP support of 3D operations is out there. But where? Where do we get a version of AIR 1.5 that can be installed on a target desktop, so that we can try to run the ADT test cycle? Call it Gumbo, call it Flex4, call it whatever, but can someone tell us how to start testing it for AIR application deployment? Thank you. ________________________________ View/reply at How to Test AIR 1.5 <a href=http://www.adobeforums.com/webx?13@@.59b6ed86> Replies by email are OK. Use the unsubscribe <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to cancel your email subscription.

Report · Nov 03, 2008

Thanks for the quick turnaround. Pardon my ignorance, but exactly what .exe file will install Air 1.5 on a system? I don't find it anywhere. I guess I can try to tear the ADL source apart to see how it mimics that behavior, but that is, at best, just a local test. I think testing the whole Badge install sequence is essential, and would like to give it a try. The longer we put this off, the longer we all just sit here trying to decide whether to stay with Papervision, Away, Sandy, or to use the graphics support in the Player. I am busy making the dynamic link to the framework.swz work for Flex modules running under an AIR shell, and I doubt that I am alone. There must be many of us who really see no distinction between AIR and Flex -- they just provide us two different ways to slice a problem, that's why it is so disconcerting to try to follow the threads on rapid Flex advancement with FP 10, but almost nothing pertaining the doing the very same things with the AIR toolkit. I hope you can tell me where to get the standalone AIR 1.5 installer that will me keep making progress with the debugging output reasonably well handled by Allesandros' FireFox tracer. Many thanks. ----- Original Message ----- From: "Matt Chotin" <member@adobeforums.com> To: <flexsdk-dev@adobeforums.com> Sent: Monday, November 03, 2008 7:55 PM Subject: Re: How to Test AIR 1.5 >A new message was posted by Matt Chotin in > > Developers -- > How to Test AIR 1.5 > > Hi, > > We're not doing a public beta of the release runtime for AIR 1.5. You can > use the debug runtimes that are part of the Flex nightly builds though > (check the Flex 3 nightlies) to validate that AIR 1.5 will be right for > you though. > > Matt > > On 11/3/08 7:38 PM, "Terry Corbet" <member@adobeforums.com> wrote: > > A new discussion was started by Terry Corbet in > > Developers -- > How to Test AIR 1.5 > > Sorry if this seems slightly off center, but I blame Adobe, not myself. > Trying to determine the true status and positioning of AIR amongst the > various Flex forums and projects for an outsider is practically > impossible. So, I will be brief. In September Mr. Chambers sent opened > the flow by telling us that we could find FP10 integrated with Flex SDK in > something you call 1.5 or Cosmo, or both. He was properly circumspect, so > I didn't rush into it -- there was not even an ADL binary when I checked. > Now it is November, the Trunk is at 4005, and ostensibly, everything we > need to start trying to take advantage of FP support of 3D operations is > out there. But where? Where do we get a version of AIR 1.5 that can be > installed on a target desktop, so that we can try to run the ADT test > cycle? > > Call it Gumbo, call it Flex4, call it whatever, but can someone tell us > how to start testing it for AIR application deployment? > > Thank you. > > ________________________________ > View/reply at How to Test AIR 1.5 > <a href=http://www.adobeforums.com/webx?13@@.59b6ed86> > Replies by email are OK. > Use the unsubscribe > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to > cancel your email subscription. > > > > > ------------------------------------------------------ > View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/0> > Replies by email are OK. > Use the unsubscribe form at > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to > cancel your email subscription.

Report · Nov 03, 2008

The badge install doesn't work with debug, you can only use adl.exe right now. But this should show how the whole system would work and really allow you to evaluate. You know how the AIR install works with Air 1.1 (if not, use Flex 3.1 to target 1.1), I don't think seeing it with AIR 1.5 is critical to evaluate the features of the runtime at this point. Air and the Flash Player are runtimes, and we've made it clear that AIR 1.5 would include FP10 features. So when we say Flex will enable FP10, it should be obvious that when AIR 1.5 comes out Flex will support it in the same way. I don't really understand what you're doing with the SWZ and AIR, there's no real need to use a cached framework when the whole app is going to be installed. In any case, Air 1.5 should be out in 2 weeks hopefully so you'll be set then. Matt On 11/3/08 8:07 PM, "Terry Corbet" <member@adobeforums.com> wrote: A new message was posted by Terry Corbet in Developers -- How to Test AIR 1.5 Thanks for the quick turnaround. Pardon my ignorance, but exactly what .exe file will install Air 1.5 on a system? I don't find it anywhere. I guess I can try to tear the ADL source apart to see how it mimics that behavior, but that is, at best, just a local test. I think testing the whole Badge install sequence is essential, and would like to give it a try. The longer we put this off, the longer we all just sit here trying to decide whether to stay with Papervision, Away, Sandy, or to use the graphics support in the Player. I am busy making the dynamic link to the framework.swz work for Flex modules running under an AIR shell, and I doubt that I am alone. There must be many of us who really see no distinction between AIR and Flex -- they just provide us two different ways to slice a problem, that's why it is so disconcerting to try to follow the threads on rapid Flex advancement with FP 10, but almost nothing pertaining the doing the very same things with the AIR toolkit. I hope you can tell me where to get the standalone AIR 1.5 installer that will me keep making progress with the debugging output reasonably well handled by Allesandros' FireFox tracer. Many thanks. ----- Original Message ----- From: "Matt Chotin" <member@adobeforums.com> To: <flexsdk-dev@adobeforums.com> Sent: Monday, November 03, 2008 7:55 PM Subject: Re: How to Test AIR 1.5 >A new message was posted by Matt Chotin in > > Developers -- > How to Test AIR 1.5 > > Hi, > > We're not doing a public beta of the release runtime for AIR 1.5. You can > use the debug runtimes that are part of the Flex nightly builds though > (check the Flex 3 nightlies) to validate that AIR 1.5 will be right for > you though. > > Matt > > On 11/3/08 7:38 PM, "Terry Corbet" <member@adobeforums.com> wrote: > > A new discussion was started by Terry Corbet in > > Developers -- > How to Test AIR 1.5 > > Sorry if this seems slightly off center, but I blame Adobe, not myself. > Trying to determine the true status and positioning of AIR amongst the > various Flex forums and projects for an outsider is practically > impossible. So, I will be brief. In September Mr. Chambers sent opened > the flow by telling us that we could find FP10 integrated with Flex SDK in > something you call 1.5 or Cosmo, or both. He was properly circumspect, so > I didn't rush into it -- there was not even an ADL binary when I checked. > Now it is November, the Trunk is at 4005, and ostensibly, everything we > need to start trying to take advantage of FP support of 3D operations is > out there. But where? Where do we get a version of AIR 1.5 that can be > installed on a target desktop, so that we can try to run the ADT test > cycle? > > Call it Gumbo, call it Flex4, call it whatever, but can someone tell us > how to start testing it for AIR application deployment? > > Thank you. > > ________________________________ > View/reply at How to Test AIR 1.5 > <a href=http://www.adobeforums.com/webx?13@@.59b6ed86> > Replies by email are OK. > Use the unsubscribe > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to > cancel your email subscription. > > > > > ------------------------------------------------------ > View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/0> > Replies by email are OK. > Use the unsubscribe form at > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to > cancel your email subscription. ------------------------------------------------------ View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/1> Replies by email are OK. Use the unsubscribe form at <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.

Report · Nov 03, 2008

01. Thanks, I will continue testing with ADL and hopefully be able to move up to a web-base, remote installation/update scenario in a couple of weeks. 02. I'm sorry you feel that my failure to accept what may be 'intuitively obvious to you' -- that I can design and test a 3D front end to FMS that works the same in a native window as in a browser window -- indicates any lack of faith in what will be delivered. So far, I have found subtle, important differences, and I am sure there will be others that will just have to be patiently tested before I get it right. 03. So, I'm glad you asked about swz in an AIR environment because that is a whole topic for which I have not been able to find any discussion on any of the many fine forums you have. I understand product marketing and product development, but I can't say that I ever managed those activities in the environment you have in which several large projects co-exist with lingering dependencies and even 'cultures' as diverse as you have with the various acquisitions that come together in the suite of products you have today. So, I will simply state that I think no one seems to have recognized that your paradigm for 'desktop' versus 'web-based' software -- the essential distinction which seems to describe Adobe's description of an AIR versus a Flex application -- does not always hold. I understand the general dichotomy, but it does not hold for my user base. You have lots of design papers and lots of software devoted to 'reducing the burden' of ever-growing executables in the Flex framework by caching of your or our rsls. That's a good idea. Why do you think it is not just as good an idea for an AIR application? Probably because you think that an AIR application will either be shipped on a CD, or sent over the Internet, but relatively infrequently, so who cares if you have to ship out 10MBs or 2MBs? My user cares. My user will get frequent updates to an ever-growing body of software called an application, and he will get them over those same slow bandwidth network links that the Flex user sees. What's "good for the goose is good for the gander". There is simply no reason not to architect the library of code that we use to cobble together the application and use the same intelligent caching mechanism in both environments. I looked for a month for a white paper or discussion of how to 'modularize' an AIR app but all that you wanted to publish were white papers on how to 'modularize' a Flex app. I'm sure that you guys have a bunch of object diagrams and product architecture blueprints that you have memorized -- but that is not what we see 'outside the black box'. What we see is a confusing distinction between the AIR efforts and the Flex efforts although the code base and efforts are substantially the same. And if that is true from an internals point of view, put on your end-user hat and look at how we view a AIR/Flex app -- it is all one. So, I develop the worlds greatest Juke Box and get it all going in Flex, then I move that into one Tab on one Screen in the AIR 'shell'. Then some guys go off and mostly use AIR-unique code to add a Tab that allows Drag and Drop creation of Slide Shows accompanied by voice overs, and another set of my guys go off to add the 'Sudoku' module in just plain old Flex. At some point in time in some ant task, we've got 10MB of code and X MBs of that is in one of our present [or future] swz files. Where is the distinction that says I should just ask my users to download the whole shooting match, when what he really wants to do is just download whatever updated or new application modules [including any upgrades to your frameworks] when required. So, it took some time, but today, my application is compiled with dynamic linking to the framework.swz, and when the user launches his AIR application on the desktop, the Flash Player, embedded in the AIR environment, is smart enough to find that it already has the necessary framework code and does not need to go back to the network to get it refreshed. Actually, since I could never figure out how to use Module and ModuleManager, the method for solving the framework caching problem ended up just being an extension of what I developed for version management 'with continuous update' of my own swf files. So, when the AIR shell starts up, it needs to test to see whether there is any updating to be done, or whether it already has locally available the 'latest and greatest' and that works the same for MyCute3DWizBang.swf or framework_3.1.0.2710.swz or framework_4.0.0.3988.swf. If you take the point of view that a 'desktop application' doesn't need to do anything special to solve the problem of 'large file downloads', you end up thinking that there is no reason for an AIR application to take advantage of the frameworked cache when, in fact, almost all of that code is needed whether the execution thread starts in a 'WindowApplication' or just a plain old 'Application'. At least thats the cockamaymee point of view that I came to in the absence of any 'best practice' discussion of these key topics -- so far, it seems to be working pretty well, but as you can guess, testing across a network to a remote host that may or may not have the right version of AIR, or the right version of framework, or the right version of MyCute3DWizBang is really more important than just testing against ADL. ----- Original Message ----- From: "Matt Chotin" <member@adobeforums.com> To: <flexsdk-dev@adobeforums.com> Sent: Monday, November 03, 2008 8:39 PM Subject: Re: How to Test AIR 1.5 >A new message was posted by Matt Chotin in > > Developers -- > How to Test AIR 1.5 > > The badge install doesn't work with debug, you can only use adl.exe right > now. But this should show how the whole system would work and really > allow you to evaluate. You know how the AIR install works with Air 1.1 > (if not, use Flex 3.1 to target 1.1), I don't think seeing it with AIR 1.5 > is critical to evaluate the features of the runtime at this point. > > Air and the Flash Player are runtimes, and we've made it clear that AIR > 1.5 would include FP10 features. So when we say Flex will enable FP10, it > should be obvious that when AIR 1.5 comes out Flex will support it in the > same way. > > I don't really understand what you're doing with the SWZ and AIR, there's > no real need to use a cached framework when the whole app is going to be > installed. > > In any case, Air 1.5 should be out in 2 weeks hopefully so you'll be set > then. > > Matt > > On 11/3/08 8:07 PM, "Terry Corbet" <member@adobeforums.com> wrote: > > A new message was posted by Terry Corbet in > > Developers -- > How to Test AIR 1.5 > > Thanks for the quick turnaround. Pardon my ignorance, but exactly what > .exe > file will install Air 1.5 on a system? I don't find it anywhere. I guess > I > can try to tear the ADL source apart to see how it mimics that behavior, > but > that is, at best, just a local test. I think testing the whole Badge > install sequence is essential, and would like to give it a try. The > longer > we put this off, the longer we all just sit here trying to decide whether > to > stay with Papervision, Away, Sandy, or to use the graphics support in the > Player. > > I am busy making the dynamic link to the framework.swz work for Flex > modules > running under an AIR shell, and I doubt that I am alone. There must be > many > of us who really see no distinction between AIR and Flex -- they just > provide us two different ways to slice a problem, that's why it is so > disconcerting to try to follow the threads on rapid Flex advancement with > FP > 10, but almost nothing pertaining the doing the very same things with the > AIR toolkit. > > I hope you can tell me where to get the standalone AIR 1.5 installer that > will me keep making progress with the debugging output reasonably well > handled by Allesandros' FireFox tracer. Many thanks. > > > ----- Original Message ----- > From: "Matt Chotin" <member@adobeforums.com> > To: <flexsdk-dev@adobeforums.com> > Sent: Monday, November 03, 2008 7:55 PM > Subject: Re: How to Test AIR 1.5 > > >>A new message was posted by Matt Chotin in >> >> Developers -- >> How to Test AIR 1.5 >> >> Hi, >> >> We're not doing a public beta of the release runtime for AIR 1.5. You >> can >> use the debug runtimes that are part of the Flex nightly builds though >> (check the Flex 3 nightlies) to validate that AIR 1.5 will be right for >> you though. >> >> Matt >> >> On 11/3/08 7:38 PM, "Terry Corbet" <member@adobeforums.com> wrote: >> >> A new discussion was started by Terry Corbet in >> >> Developers -- >> How to Test AIR 1.5 >> >> Sorry if this seems slightly off center, but I blame Adobe, not myself. >> Trying to determine the true status and positioning of AIR amongst the >> various Flex forums and projects for an outsider is practically >> impossible. So, I will be brief. In September Mr. Chambers sent opened >> the flow by telling us that we could find FP10 integrated with Flex SDK >> in >> something you call 1.5 or Cosmo, or both. He was properly circumspect, >> so >> I didn't rush into it -- there was not even an ADL binary when I checked. >> Now it is November, the Trunk is at 4005, and ostensibly, everything we >> need to start trying to take advantage of FP support of 3D operations is >> out there. But where? Where do we get a version of AIR 1.5 that can be >> installed on a target desktop, so that we can try to run the ADT test >> cycle? >> >> Call it Gumbo, call it Flex4, call it whatever, but can someone tell us >> how to start testing it for AIR application deployment? >> >> Thank you. >> >> ________________________________ >> View/reply at How to Test AIR 1.5 >> <a href=http://www.adobeforums.com/webx?13@@.59b6ed86> >> Replies by email are OK. >> Use the unsubscribe >> <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form >> to >> cancel your email subscription. >> >> >> >> >> ------------------------------------------------------ >> View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/0> >> Replies by email are OK. >> Use the unsubscribe form at >> <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to >> cancel your email subscription. > > > > ------------------------------------------------------ > View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/1> > Replies by email are OK. > Use the unsubscribe form at > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to > cancel your email subscription. > > > > ------------------------------------------------------ > View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/2> > Replies by email are OK. > Use the unsubscribe form at > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to > cancel your email subscription.

Report · Nov 03, 2008

I'm sure there's nothing stopping you from loading SWFs and SWZs and SWCs and loading them in AIR? Just treat them as normal files, and use whatever you please to push out updates etc?

-Josh

On Tue, Nov 4, 2008 at 4:53 PM, Terry Corbet < member@adobeforums.com> wrote:

A new message was posted by Terry Corbet in

Developers --

How to Test AIR 1.5

01. Thanks, I will continue testing with ADL and hopefully be able to move up to a web-base, remote installation/update scenario in a couple of weeks.

02. I'm sorry you feel that my failure to accept what may be 'intuitively obvious to you' -- that I can design and test a 3D front end to FMS that works the same in a native window as in a browser window -- indicates any lack of faith in what will be delivered. So far, I have found subtle, important differences, and I am sure there will be others that will just have to be patiently tested before I get it right.

03. So, I'm glad you asked about swz in an AIR environment because that is a whole topic for which I have not been able to find any discussion on any of the many fine forums you have. I understand product marketing and product development, but I can't say that I ever managed those activities in the environment you have in which several large projects co-exist with lingering dependencies and even 'cultures' as diverse as you have with the various acquisitions that come together in the suite of products you have today.

So, I will simply state that I think no one seems to have recognized that your paradigm for 'desktop' versus 'web-based' software -- the essential distinction which seems to describe Adobe's description of an AIR versus a Flex application -- does not always hold. I understand the general dichotomy, but it does not hold for my user base.

You have lots of design papers and lots of software devoted to 'reducing the burden' of ever-growing executables in the Flex framework by caching of your or our rsls. That's a good idea. Why do you think it is not just as good an idea for an AIR application? Probably because you think that an AIR application will either be shipped on a CD, or sent over the Internet, but relatively infrequently, so who cares if you have to ship out 10MBs or 2MBs? My user cares.

My user will get frequent updates to an ever-growing body of software called an application, and he will get them over those same slow bandwidth network links that the Flex user sees. What's "good for the goose is good for the gander". There is simply no reason not to architect the library of code that we use to cobble together the application and use the same intelligent caching mechanism in both environments. I looked for a month for a white paper or discussion of how to 'modularize' an AIR app but all that you wanted to publish were white papers on how to 'modularize' a Flex app.

I'm sure that you guys have a bunch of object diagrams and product architecture blueprints that you have memorized -- but that is not what we see 'outside the black box'. What we see is a confusing distinction between the AIR efforts and the Flex efforts although the code base and efforts are substantially the same. And if that is true from an internals point of view, put on your end-user hat and look at how we view a AIR/Flex app -- it is all one.

So, I develop the worlds greatest Juke Box and get it all going in Flex, then I move that into one Tab on one Screen in the AIR 'shell'. Then some guys go off and mostly use AIR-unique code to add a Tab that allows Drag and Drop creation of Slide Shows accompanied by voice overs, and another set of my guys go off to add the 'Sudoku' module in just plain old Flex. At some point in time in some ant task, we've got 10MB of code and X MBs of that is in one of our present [or future] swz files. Where is the distinction that says I should just ask my users to download the whole shooting match, when what he really wants to do is just download whatever updated or new application modules [including any upgrades to your frameworks] when required.

So, it took some time, but today, my application is compiled with dynamic linking to the framework.swz, and when the user launches his AIR application on the desktop, the Flash Player, embedded in the AIR environment, is smart enough to find that it already has the necessary framework code and does not need to go back to the network to get it refreshed. Actually, since I could never figure out how to use Module and ModuleManager, the method for solving the framework caching problem ended up just being an extension of what I developed for version management 'with continuous update' of my own swf files. So, when the AIR shell starts up, it needs to test to see whether there is any updating to be done, or whether it already has locally available the 'latest and greatest' and that works the same for MyCute3DWizBang.swf or framework_3.1.0.2710.swz or framework_4.0.0.3988.swf.

If you take the point of view that a 'desktop application' doesn't need to do anything special to solve the problem of 'large file downloads', you end up thinking that there is no reason for an AIR application to take advantage of the frameworked cache when, in fact, almost all of that code is needed whether the execution thread starts in a 'WindowApplication' or just a plain old 'Application'. At least thats the cockamaymee point of view that I came to in the absence of any 'best practice' discussion of these key topics -- so far, it seems to be working pretty well, but as you can guess, testing across a network to a remote host that may or may not have the right version of AIR, or the right version of framework, or the right version of MyCute3DWizBang is really more important than just testing against ADL.

----- Original Message ----- From: "Matt Chotin" < member@adobeforums.com>

To: < flexsdk-dev@adobeforums.com>

Sent: Monday, November 03, 2008 8:39 PM

Subject: Re: How to Test AIR 1.5

A new message was posted by Matt Chotin in

Developers --

How to Test AIR 1.5

The badge install doesn't work with debug, you can only use adl.exe right now. But this should show how the whole system would work and really allow you to evaluate. You know how the AIR install works with Air 1.1 (if not, use Flex 3.1 to target 1.1), I don't think seeing it with AIR 1.5 is critical to evaluate the features of the runtime at this point.

Air and the Flash Player are runtimes, and we've made it clear that AIR 1.5 would include FP10 features. So when we say Flex will enable FP10, it should be obvious that when AIR 1.5 comes out Flex will support it in the same way.

I don't really understand what you're doing with the SWZ and AIR, there's no real need to use a cached framework when the whole app is going to be installed.

In any case, Air 1.5 should be out in 2 weeks hopefully so you'll be set then.

Matt

On 11/3/08 8:07 PM, "Terry Corbet" < member@adobeforums.com> wrote:

A new message was posted by Terry Corbet in

Developers --

How to Test AIR 1.5

Thanks for the quick turnaround. Pardon my ignorance, but exactly what .exe

file will install Air 1.5 on a system? I don't find it anywhere. I guess I

can try to tear the ADL source apart to see how it mimics that behavior, but

that is, at best, just a local test. I think testing the whole Badge

install sequence is essential, and would like to give it a try. The longer

we put this off, the longer we all just sit here trying to decide whether to

stay with Papervision, Away, Sandy, or to use the graphics support in the

Player.

I am busy making the dynamic link to the framework.swz work for Flex modules

running under an AIR shell, and I doubt that I am alone. There must be many

of us who really see no distinction between AIR and Flex -- they just

provide us two different ways to slice a problem, that's why it is so

disconcerting to try to follow the threads on rapid Flex advancement with FP

10, but almost nothing pertaining the doing the very same things with the

AIR toolkit.

I hope you can tell me where to get the standalone AIR 1.5 installer that

will me keep making progress with the debugging output reasonably well

handled by Allesandros' FireFox tracer. Many thanks.

----- Original Message -----

From: "Matt Chotin" < member@adobeforums.com>

To: < flexsdk-dev@adobeforums.com>

Sent: Monday, November 03, 2008 7:55 PM

Subject: Re: How to Test AIR 1.5

A new message was posted by Matt Chotin in

Developers --

How to Test AIR 1.5

Hi,

We're not doing a public beta of the release runtime for AIR 1.5. You can

use the debug runtimes that are part of the Flex nightly builds though

(check the Flex 3 nightlies) to validate that AIR 1.5 will be right for

you though.

Matt

On 11/3/08 7:38 PM, "Terry Corbet" < member@adobeforums.com> wrote:

A new discussion was started by Terry Corbet in

Developers --

How to Test AIR 1.5

Sorry if this seems slightly off center, but I blame Adobe, not myself.

Trying to determine the true status and positioning of AIR amongst the

various Flex forums and projects for an outsider is practically

impossible. So, I will be brief. In September Mr. Chambers sent opened

the flow by telling us that we could find FP10 integrated with Flex SDK in

something you call 1.5 or Cosmo, or both. He was properly circumspect, so

I didn't rush into it -- there was not even an ADL binary when I checked.

Now it is November, the Trunk is at 4005, and ostensibly, everything we

need to start trying to take advantage of FP support of 3D operations is

out there. But where? Where do we get a version of AIR 1.5 that can be

installed on a target desktop, so that we can try to run the ADT test

cycle?

Call it Gumbo, call it Flex4, call it whatever, but can someone tell us

how to start testing it for AIR application deployment?

Thank you.

________________________________

View/reply at How to Test AIR 1.5

< http://www.adobeforums.com/webx?13@@.59b6ed86>

Replies by email are OK.

Use the unsubscribe

< http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to

cancel your email subscription.

------------------------------------------------------

View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/0>

Replies by email are OK.

Use the unsubscribe form at

< http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to

cancel your email subscription.

------------------------------------------------------

View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/1>

Replies by email are OK.

Use the unsubscribe form at < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.

------------------------------------------------------

View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/2>

Replies by email are OK.

Use the unsubscribe form at < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.

------------------------------------------------------

View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/3>

Replies by email are OK.

Use the unsubscribe form at < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.

--
"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

Report · Nov 03, 2008

<DIV>I am sure you are right about an AIR application being able to use Loader and SWFLoader. I hope I have more or less figured out the right way to do that. But, I guess my point is that none of the documentation I have been able to find anywhere would answer the question about what to do with the framework and/or rpc files. What, as far as you understand it, is the correct way to manage the use of the Aface=Arial size=2>dobe swz files in an AIR application?</DIV> <BLOCKQUOTE style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV> <DIV style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From: <A title=member@adobeforums.com href="mailto:member@adobeforums.com">Josh McDonald</A> </DIV> <DIV style="FONT: 10pt arial">To: <A title=flexsdk-dev@adobeforums.com href="mailto:flexsdk-dev@adobeforums.com">flexsdk-dev@adobeforums.com</A> </DIV> <DIV style="FONT: 10pt arial">Sent: Monday, November 03, 2008 11:01 PM</DIV> <DIV style="FONT: 10pt arial">Subject: Re: How to Test AIR 1.5</DIV> <DIV> </DIV>A new message was posted by Josh McDonald in Developers -- How to Test AIR 1.5 I'm sure there's nothing stopping you from loading SWFs and SWZs and SWCs and loading them in AIR? Just treat them as normal files, and use whatever you please to push out updates etc? -Josh On Tue, Nov 4, 2008 at 4:53 PM, Terry Corbet <<A href="mailto:member@adobeforums.com">member@adobeforums.com</A>> wrote: <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">A new message was posted by Terry Corbet in Developers -- How to Test AIR 1.5 01. Thanks, I will continue testing with ADL and hopefully be able to move up to a web-base, remote installation/update scenario in a couple of weeks. 02. I'm sorry you feel that my failure to accept what may be 'intuitively obvious to you' -- that I can design and test a 3D front end to FMS that works the same in a native window as in a browser window -- indicates any lack of faith in what will be delivered. So far, I have found subtle, important differences, and I am sure there will be others that will just have to be patiently tested before I get it right. 03. So, I'm glad you asked about swz in an AIR environment because that is a whole topic for which I have not been able to find any discussion on any of the many fine forums you have. I understand product marketing and product development, but I can't say that I ever managed those activities in the environment you have in which several large projects co-exist with lingering dependencies and even 'cultures' as diverse as you have with the various acquisitions that come together in the suite of products you have today. So, I will simply state that I think no one seems to have recognized that your paradigm for 'desktop' versus 'web-based' software -- the essential distinction which seems to describe Adobe's description of an AIR versus a Flex application -- does not always hold. I understand the general dichotomy, but it does not hold for my user base. You have lots of design papers and lots of software devoted to 'reducing the burden' of ever-growing executables in the Flex framework by caching of your or our rsls. That's a good idea. Why do you think it is not just as good an idea for an AIR application? Probably because you think that an AIR application will either be shipped on a CD, or sent over the Internet, but relatively infrequently, so who cares if you have to ship out 10MBs or 2MBs? My user cares. My user will get frequent updates to an ever-growing body of software called an application, and he will get them over those same slow bandwidth network links that the Flex user sees. What's "good for the goose is good for the gander". There is simply no reason not to architect the library of code that we use to cobble together the application and use the same intelligent caching mechanism in both environments. I looked for a month for a white paper or discussion of how to 'modularize' an AIR app but all that you wanted to publish were white papers on how to 'modularize' a Flex app. I'm sure that you guys have a bunch of object diagrams and product architecture blueprints that you have memorized -- but that is not what we see 'outside the black box'. What we see is a confusing distinction between the AIR efforts and the Flex efforts although the code base and efforts are substantially the same. And if that is true from an internals point of view, put on your end-user hat and look at how we view a AIR/Flex app -- it is all one. So, I develop the worlds greatest Juke Box and get it all going in Flex, then I move that into one Tab on one Screen in the AIR 'shell'. Then some guys go off and mostly use AIR-unique code to add a Tab that allows Drag and Drop creation of Slide Shows accompanied by voice overs, and another set of my guys go off to add the 'Sudoku' module in just plain old Flex. At some point in time in some ant task, we've got 10MB of code and X MBs of that is in one of our present [or future] swz files. Where is the distinction that says I should just ask my users to download the whole shooting match, when what he really wants to do is just download whatever updated or new application modules [including any upgrades to your frameworks] when required. So, it took some time, but today, my application is compiled with dynamic linking to the framework.swz, and when the user launches his AIR application on the desktop, the Flash Player, embedded in the AIR environment, is smart enough to find that it already has the necessary framework code and does not need to go back to the network to get it refreshed. Actually, since I could never figure out how to use Module and ModuleManager, the method for solving the framework caching problem ended up just being an extension of what I developed for version management 'with continuous update' of my own swf files. So, when the AIR shell starts up, it needs to test to see whether there is any updating to be done, or whether it already has locally available the 'latest and greatest' and that works the same for MyCute3DWizBang.swf or framework_3.1.0.2710.swz or framework_4.0.0.3988.swf. If you take the point of view that a 'desktop application' doesn't need to do anything special to solve the problem of 'large file downloads', you end up thinking that there is no reason for an AIR application to take advantage of the frameworked cache when, in fact, almost all of that code is needed whether the execution thread starts in a 'WindowApplication' or just a plain old 'Application'. At least thats the cockamaymee point of view that I came to in the absence of any 'best practice' discussion of these key topics -- so far, it seems to be working pretty well, but as you can guess, testing across a network to a remote host that may or may not have the right version of AIR, or the right version of framework, or the right version of MyCute3DWizBang is really more important than just testing against ADL. ----- Original Message ----- From: "Matt Chotin" <<A href="mailto:member@adobeforums.com" target=_blank>member@adobeforums.com</A>> To: <<A href="mailto:flexsdk-dev@adobeforums.com" target=_blank>flexsdk-dev@adobeforums.com</A>> Sent: Monday, November 03, 2008 8:39 PM Subject: Re: How to Test AIR 1.5 <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">A new message was posted by Matt Chotin in Developers -- How to Test AIR 1.5 The badge install doesn't work with debug, you can only use adl.exe right now. But this should show how the whole system would work and really allow you to evaluate. You know how the AIR install works with Air 1.1 (if not, use Flex 3.1 to target 1.1), I don't think seeing it with AIR 1.5 is critical to evaluate the features of the runtime at this point. Air and the Flash Player are runtimes, and we've made it clear that AIR 1.5 would include FP10 features. So when we say Flex will enable FP10, it should be obvious that when AIR 1.5 comes out Flex will support it in the same way. I don't really understand what you're doing with the SWZ and AIR, there's no real need to use a cached framework when the whole app is going to be installed. In any case, Air 1.5 should be out in 2 weeks hopefully so you'll be set then. Matt On 11/3/08 8:07 PM, "Terry Corbet" <<A href="mailto:member@adobeforums.com" target=_blank>member@adobeforums.com</A>> wrote: A new message was posted by Terry Corbet in Developers -- How to Test AIR 1.5 Thanks for the quick turnaround. Pardon my ignorance, but exactly what .exe file will install Air 1.5 on a system? I don't find it anywhere. I guess I can try to tear the ADL source apart to see how it mimics that behavior, but that is, at best, just a local test. I think testing the whole Badge install sequence is essential, and would like to give it a try. The longer we put this off, the longer we all just sit here trying to decide whether to stay with Papervision, Away, Sandy, or to use the graphics support in the Player. I am busy making the dynamic link to the framework.swz work for Flex modules running under an AIR shell, and I doubt that I am alone. There must be many of us who really see no distinction between AIR and Flex -- they just provide us two different ways to slice a problem, that's why it is so disconcerting to try to follow the threads on rapid Flex advancement with FP 10, but almost nothing pertaining the doing the very same things with the AIR toolkit. I hope you can tell me where to get the standalone AIR 1.5 installer that will me keep making progress with the debugging output reasonably well handled by Allesandros' FireFox tracer. Many thanks. ----- Original Message ----- From: "Matt Chotin" <<A href="mailto:member@adobeforums.com" target=_blank>member@adobeforums.com</A>> To: <<A href="mailto:flexsdk-dev@adobeforums.com" target=_blank>flexsdk-dev@adobeforums.com</A>> Sent: Monday, November 03, 2008 7:55 PM Subject: Re: How to Test AIR 1.5 <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">A new message was posted by Matt Chotin in Developers -- How to Test AIR 1.5 Hi, We're not doing a public beta of the release runtime for AIR 1.5. You can use the debug runtimes that are part of the Flex nightly builds though (check the Flex 3 nightlies) to validate that AIR 1.5 will be right for you though. Matt On 11/3/08 7:38 PM, "Terry Corbet" <<A href="mailto:member@adobeforums.com" target=_blank>member@adobeforums.com</A>> wrote: A new discussion was started by Terry Corbet in Developers -- How to Test AIR 1.5 Sorry if this seems slightly off center, but I blame Adobe, not myself. Trying to determine the true status and positioning of AIR amongst the various Flex forums and projects for an outsider is practically impossible. So, I will be brief. In September Mr. Chambers sent opened the flow by telling us that we could find FP10 integrated with Flex SDK in something you call 1.5 or Cosmo, or both. He was properly circumspect, so I didn't rush into it -- there was not even an ADL binary when I checked. Now it is November, the Trunk is at 4005, and ostensibly, everything we need to start trying to take advantage of FP support of 3D operations is out there. But where? Where do we get a version of AIR 1.5 that can be installed on a target desktop, so that we can try to run the ADT test cycle? Call it Gumbo, call it Flex4, call it whatever, but can someone tell us how to start testing it for AIR application deployment? Thank you. ________________________________ View/reply at How to Test AIR 1.5 <<A href="http://www.adobeforums.com/webx?13@@.59b6ed86" target=_blank>http://www.adobeforums.com/webx?13@@.59b6ed86</A>> Replies by email are OK. Use the unsubscribe <<A href="http://www.adobeforums.com/webx?280@@.59b6ed86%21folder=.3c060fa3" target=_blank>http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3</A>> form to cancel your email subscription. ------------------------------------------------------ View/reply at <<A href="http://www.adobeforums.com/webx?13@@.59b6ed86/0" target=_blank>http://www.adobeforums.com/webx?13@@.59b6ed86/0</A>> Replies by email are OK. Use the unsubscribe form at <<A href="http://www.adobeforums.com/webx?280@@.59b6ed86%21folder=.3c060fa3" target=_blank>http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3</A>> to cancel your email subscription. </BLOCKQUOTE> ------------------------------------------------------ View/reply at <<A href="http://www.adobeforums.com/webx?13@@.59b6ed86/1" target=_blank>http://www.adobeforums.com/webx?13@@.59b6ed86/1</A>> Replies by email are OK. Use the unsubscribe form at <<A href="http://www.adobeforums.com/webx?280@@.59b6ed86%21folder=.3c060fa3" target=_blank>http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3</A>> to cancel your email subscription. ------------------------------------------------------ View/reply at <<A href="http://www.adobeforums.com/webx?13@@.59b6ed86/2" target=_blank>http://www.adobeforums.com/webx?13@@.59b6ed86/2</A>> Replies by email are OK. Use the unsubscribe form at <<A href="http://www.adobeforums.com/webx?280@@.59b6ed86%21folder=.3c060fa3" target=_blank>http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3</A>> to cancel your email subscription. </BLOCKQUOTE> ------------------------------------------------------ View/reply at <<A href="http://www.adobeforums.com/webx?13@@.59b6ed86/3" target=_blank>http://www.adobeforums.com/webx?13@@.59b6ed86/3</A>> Replies by email are OK. Use the unsubscribe form at <<A href="http://www.adobeforums.com/webx?280@@.59b6ed86%21folder=.3c060fa3" target=_blank>http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3</A>> to cancel your email subscription. </BLOCKQUOTE> -- "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 :: <A href="mailto:josh@gfunk007.com">josh@gfunk007.com</A> :: <A href="http://flex.joshmcdonald.info/">http://flex.joshmcdonald.info/</A> :: <A href="http://twitter.com/sophistifunk">http://twitter.com/sophistifunk</A> <HR align=left width=200> View/reply at <A href="http://www.adobeforums.com/webx?13@@.59b6ed86/4">How to Test AIR 1.5</A> Replies by email are OK. Use the <A href="http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3">unsubscribe</A> form to cancel your email subscription. </BLOCKQUOTE>

Report · Nov 09, 2008

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

Report · Nov 09, 2008

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

Report · Nov 18, 2008

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.

Report · Nov 25, 2008

Hi Terry, 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. Matt On 11/18/08 5:22 PM, "Terry Corbet" <member@adobeforums.com> wrote: A new message was posted by Terry Corbet in Developers -- How to Test AIR 1.5 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 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. ________________________________ View/reply at How to Test AIR 1.5 <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/8> Replies by email are OK. Use the unsubscribe <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to cancel your email subscription.

Report · Nov 25, 2008

Oh, and it's something you could probably patch yourself by looking at how LoaderUtils works if you don't want to wait. On 11/18/08 5:22 PM, "Terry Corbet" <member@adobeforums.com> wrote: A new message was posted by Terry Corbet in Developers -- How to Test AIR 1.5 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 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. ________________________________ View/reply at How to Test AIR 1.5 <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/8> Replies by email are OK. Use the unsubscribe <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to cancel your email subscription.

Report · Nov 25, 2008

Thanks for both replies. I will try to see if I understand LoaderUtils well enough to at least learn what caused the failure. I can wait for the fix, but what I most have really been trying to get in response to my flailing about is some sort of 'best practices' paper talking about the basic issue. With the Nov 17 roll out, I see a huge effort put into the PDF discussing "Loading Sub-Applications", but, as with security white papers and other documents about 'modularization', whenever the author needs adopt his comments/recommendations to AIR, it is like the sentence falls off the end of the earth. "Oh, yes, this doesn't quite apply to AIR." What does apply to AIR? We need a definitive statement concerning caching of Adobe frameworks when talking about AIR. Beyond that, somewhere along the way I submitted a suggestion for enhancement that included the idea that in both environments -- Flex or AIR -- the URL to which we would really like to point when it comes time to access the .swz files, is one on your servers. Even if you are dealing with the complexities of 'sub-applications' that require access to several versions of the same framework files -- or maybe especially if you are dealing with the complexities of 'sub-applications' that require access to several versions of the same framework files -- the best place to host those download requests is at Adobe. 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. Putting the framework on an Adobe server and letting the AIR runtime and the Player 'go there' whenever it sees that it is about to load a 'chunk of code' that was compiled for dynamic linkage, would just make the cross-over from Flex to AIR almost transparent. Right now that whole topic is so opaque that I am sure there are not 10 people who are trying to take advantage of the framework cache from an AIR application. Thanks again -- both Flex and AIR are superb facilities, but those Redmond guys still have a lot of clout and we have to do everything possible to stay in front of that pack. ----- Original Message ----- From: "Matt Chotin" <member@adobeforums.com> To: <flexsdk-dev@adobeforums.com> Sent: Tuesday, November 25, 2008 8:45 AM Subject: Re: How to Test AIR 1.5 >A new message was posted by Matt Chotin in > > Developers -- > How to Test AIR 1.5 > > Oh, and it's something you could probably patch yourself by looking at how > LoaderUtils works if you don't want to wait. > > > On 11/18/08 5:22 PM, "Terry Corbet" <member@adobeforums.com> wrote: > > A new message was posted by Terry Corbet in > > Developers -- > How to Test AIR 1.5 > > 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 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. > > ________________________________ > View/reply at How to Test AIR 1.5 > <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/8> > Replies by email are OK. > Use the unsubscribe > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to > cancel your email subscription. > > > > > ------------------------------------------------------ > View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/10> > Replies by email are OK. > Use the unsubscribe form at > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to > cancel your email subscription.

Report · Nov 25, 2008

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. Something we can look into in the future. Matt On 11/25/08 12:43 PM, "Terry Corbet" <member@adobeforums.com> wrote: A new message was posted by Terry Corbet in Developers -- How to Test AIR 1.5 Thanks for both replies. I will try to see if I understand LoaderUtils well enough to at least learn what caused the failure. I can wait for the fix, but what I most have really been trying to get in response to my flailing about is some sort of 'best practices' paper talking about the basic issue. With the Nov 17 roll out, I see a huge effort put into the PDF discussing "Loading Sub-Applications", but, as with security white papers and other documents about 'modularization', whenever the author needs adopt his comments/recommendations to AIR, it is like the sentence falls off the end of the earth. "Oh, yes, this doesn't quite apply to AIR." What does apply to AIR? We need a definitive statement concerning caching of Adobe frameworks when talking about AIR. Beyond that, somewhere along the way I submitted a suggestion for enhancement that included the idea that in both environments -- Flex or AIR -- the URL to which we would really like to point when it comes time to access the .swz files, is one on your servers. Even if you are dealing with the complexities of 'sub-applications' that require access to several versions of the same framework files -- or maybe especially if you are dealing with the complexities of 'sub-applications' that require access to several versions of the same framework files -- the best place to host those download requests is at Adobe. 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. Putting the framework on an Adobe server and letting the AIR runtime and the Player 'go there' whenever it sees that it is about to load a 'chunk of code' that was compiled for dynamic linkage, would just make the cross-over from Flex to AIR almost transparent. Right now that whole topic is so opaque that I am sure there are not 10 people who are trying to take advantage of the framework cache from an AIR application. Thanks again -- both Flex and AIR are superb facilities, but those Redmond guys still have a lot of clout and we have to do everything possible to stay in front of that pack. ----- Original Message ----- From: "Matt Chotin" <member@adobeforums.com> To: <flexsdk-dev@adobeforums.com> Sent: Tuesday, November 25, 2008 8:45 AM Subject: Re: How to Test AIR 1.5 >A new message was posted by Matt Chotin in > > Developers -- > How to Test AIR 1.5 > > Oh, and it's something you could probably patch yourself by looking at how > LoaderUtils works if you don't want to wait. > > > On 11/18/08 5:22 PM, "Terry Corbet" <member@adobeforums.com> wrote: > > A new message was posted by Terry Corbet in > > Developers -- > How to Test AIR 1.5 > > 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 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. > > ________________________________ > View/reply at How to Test AIR 1.5 > <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/8> > Replies by email are OK. > Use the unsubscribe > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to > cancel your email subscription. > > > > > ------------------------------------------------------ > View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/10> > Replies by email are OK. > Use the unsubscribe form at > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to > cancel your email subscription. ------------------------------------------------------ View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/11> Replies by email are OK. Use the unsubscribe form at <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.

Report · Nov 25, 2008

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

On Wed, Nov 26, 2008 at 4:26 AM, Matt Chotin < member@adobeforums.com> wrote:

A new message was posted by Matt Chotin in

Developers --

How to Test AIR 1.5

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.

Something we can look into in the future.

Matt

On 11/25/08 12:43 PM, "Terry Corbet" < member@adobeforums.com> wrote:

A new message was posted by Terry Corbet in

Developers --

How to Test AIR 1.5

Thanks for both replies. I will try to see if I understand LoaderUtils well

enough to at least learn what caused the failure. I can wait for the fix,

but what I most have really been trying to get in response to my flailing

about is some sort of 'best practices' paper talking about the basic issue.

With the Nov 17 roll out, I see a huge effort put into the PDF discussing

"Loading Sub-Applications", but, as with security white papers and other

documents about 'modularization', whenever the author needs adopt his

comments/recommendations to AIR, it is like the sentence falls off the end

of the earth. "Oh, yes, this doesn't quite apply to AIR."

What does apply to AIR? We need a definitive statement concerning caching

of Adobe frameworks when talking about AIR.

Beyond that, somewhere along the way I submitted a suggestion for

enhancement that included the idea that in both environments -- Flex or

AIR -- the URL to which we would really like to point when it comes time to

access the .swz files, is one on your servers. Even if you are dealing with

the complexities of 'sub-applications' that require access to several

versions of the same framework files -- or maybe especially if you are

dealing with the complexities of 'sub-applications' that require access to

several versions of the same framework files -- the best place to host those

download requests is at Adobe.

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. Putting the framework on an Adobe server and letting the AIR

runtime and the Player 'go there' whenever it sees that it is about to load

a 'chunk of code' that was compiled for dynamic linkage, would just make the

cross-over from Flex to AIR almost transparent. Right now that whole topic

is so opaque that I am sure there are not 10 people who are trying to take

advantage of the framework cache from an AIR application.

Thanks again -- both Flex and AIR are superb facilities, but those Redmond

guys still have a lot of clout and we have to do everything possible to stay

in front of that pack.

----- Original Message -----

From: "Matt Chotin" < member@adobeforums.com>

To: < flexsdk-dev@adobeforums.com>

Sent: Tuesday, November 25, 2008 8:45 AM

Subject: Re: How to Test AIR 1.5

>A new message was posted by Matt Chotin in

>

> Developers --

> How to Test AIR 1.5

>

> Oh, and it's something you could probably patch yourself by looking at how

> LoaderUtils works if you don't want to wait.

>

>

> On 11/18/08 5:22 PM, "Terry Corbet" < member@adobeforums.com> wrote:

>

> A new message was posted by Terry Corbet in

>

> Developers --

> How to Test AIR 1.5

>

> 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 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.

>

> ________________________________

> View/reply at How to Test AIR 1.5

> < http://www.adobeforums.com/webx?13@@.59b6ed86/8>

> Replies by email are OK.

> Use the unsubscribe

> < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to

> cancel your email subscription.

>

>

>

>

> ------------------------------------------------------

> View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/10>

> Replies by email are OK.

> Use the unsubscribe form at

> < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to

> cancel your email subscription.

------------------------------------------------------

View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/11>

Replies by email are OK.

Use the unsubscribe form at < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.

------------------------------------------------------

View/reply at < http://www.adobeforums.com/webx?13@@.59b6ed86/12>

Replies by email are OK.

Use the unsubscribe form at < http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.

--
"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

Report · Nov 26, 2008

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.

Report · Nov 26, 2008

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.

Report · Nov 26, 2008

The fix to the problem you are seeing on AIR is written up in this bug: https://bugs.adobe.com/jira/browse/SDK-18202. The bug has been fixed in the 3.x branch. In the "Workaround" section of the bug I explained how you can patch your application when using the 3.2.0 SDK. -Darrell -----Original Message----- From: Terry Corbet [mailto:member@adobeforums.com] Sent: Tuesday, November 25, 2008 12:43 PM To: flexsdk-dev@adobeforums.com Subject: Re: How to Test AIR 1.5 A new message was posted by Terry Corbet in Developers -- How to Test AIR 1.5 Thanks for both replies. I will try to see if I understand LoaderUtils well enough to at least learn what caused the failure. I can wait for the fix, but what I most have really been trying to get in response to my flailing about is some sort of 'best practices' paper talking about the basic issue. With the Nov 17 roll out, I see a huge effort put into the PDF discussing "Loading Sub-Applications", but, as with security white papers and other documents about 'modularization', whenever the author needs adopt his comments/recommendations to AIR, it is like the sentence falls off the end of the earth. "Oh, yes, this doesn't quite apply to AIR." What does apply to AIR? We need a definitive statement concerning caching of Adobe frameworks when talking about AIR. Beyond that, somewhere along the way I submitted a suggestion for enhancement that included the idea that in both environments -- Flex or AIR -- the URL to which we would really like to point when it comes time to access the .swz files, is one on your servers. Even if you are dealing with the complexities of 'sub-applications' that require access to several versions of the same framework files -- or maybe especially if you are dealing with the complexities of 'sub-applications' that require access to several versions of the same framework files -- the best place to host those download requests is at Adobe. 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. Putting the framework on an Adobe server and letting the AIR runtime and the Player 'go there' whenever it sees that it is about to load a 'chunk of code' that was compiled for dynamic linkage, would just make the cross-over from Flex to AIR almost transparent. Right now that whole topic is so opaque that I am sure there are not 10 people who are trying to take advantage of the framework cache from an AIR application. Thanks again -- both Flex and AIR are superb facilities, but those Redmond guys still have a lot of clout and we have to do everything possible to stay in front of that pack. ----- Original Message ----- From: "Matt Chotin" <member@adobeforums.com> To: <flexsdk-dev@adobeforums.com> Sent: Tuesday, November 25, 2008 8:45 AM Subject: Re: How to Test AIR 1.5 >A new message was posted by Matt Chotin in > > Developers -- > How to Test AIR 1.5 > > Oh, and it's something you could probably patch yourself by looking at how > LoaderUtils works if you don't want to wait. > > > On 11/18/08 5:22 PM, "Terry Corbet" <member@adobeforums.com> wrote: > > A new message was posted by Terry Corbet in > > Developers -- > How to Test AIR 1.5 > > 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 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. > > ________________________________ > View/reply at How to Test AIR 1.5 > <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/8> > Replies by email are OK. > Use the unsubscribe > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to > cancel your email subscription. > > > > > ------------------------------------------------------ > View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/10> > Replies by email are OK. > Use the unsubscribe form at > <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to > cancel your email subscription. ------------------------------------------------------ View/reply at <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/11> Replies by email are OK. Use the unsubscribe form at <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> to cancel your email subscription.

Report · Nov 26, 2008

Darrell,

Thanks for monitoring this thread and for your suggestion. I know that this is not the forum for bug reporting, so I will wrap this thread up and follow up over there.

This thread was started in the hopes of getting a clear, positive white paper to deal with the disconnect between discussions of 'modularization' in an AIR/Flex application as contrasted with just a plain old Flex application, and maybe there is now enough interest that someone will consider doing that.

Report · Nov 26, 2008

<div class=Section1> color:#1F497D'>Darrell’s suggestion will be the “official” answer until 3.3 or whatever it ends up being ships.<o:p></o:p> color:#1F497D'><o:p> </o:p> color:#1F497D'>Per your other point, IMHO it is too early for a white paper. AIR is too new to want to put a stake in the ground on the right way to modularize AIR apps. Because it is new, its security model is pretty conservative and actually gets in the way of some of these modularization strategies. It will be through feedback from folks like you who have a vision of a particular application configuration that will help us prioritize and shape the security model and modularization techniques going forward.<o:p></o:p> color:#1F497D'><o:p> </o:p> color:#1F497D'>Right now, any attempt to have an AIR application load any kind of code modules from the internet runs into one wall or another. You cannot currently trust that code from the internet enough to allow it access to desktop features that differentiate AIR from Flash. Folks workaround it by using loadBytes, but I certainly wouldn’t publish that as the recommended technique. Instead, we want to feedback on such things as what kind of authentication you’d be willing to go through to trust that code, how important is it to you that said code have access to desktop features, what other levels of integration is a must-have between those modules of code. In the Marshall Plan, we discuss how modules are not the same as sub-applications and serve different purposes. What purposes are you trying to solve with code from the internet? Does your AIR application have online/offline capabilities and how do you plan to handle unavailability of the network? Would you prefer to bring code down and install and only update it when necessary instead of pulling it from the internet each time you start it up? Or are you willing to pay the delayed startup time of always having the bytes come over the wire instead of off the disk?<o:p></o:p> color:#1F497D'><o:p> </o:p> color:#1F497D'>My 2 cents,<o:p></o:p> color:#1F497D'>-Alex<o:p></o:p> color:#1F497D'><o:p> </o:p> color:#1F497D'><o:p> </o:p> <div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'> From:<span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Terry Corbet [mailto:member@adobeforums.com] Sent: Wednesday, November 26, 2008 3:16 PM To: flexsdk-dev@adobeforums.com Subject: Re: How to Test AIR 1.5<o:p></o:p> </div> <o:p> </o:p> A new message was posted by Terry Corbet in Developers -- How to Test AIR 1.5 Darrell, Thanks for monitoring this thread and for your suggestion. I know that this is not the forum for bug reporting, so I will wrap this thread up and follow up over there. This thread was started in the hopes of getting a clear, positive white paper to deal with the disconnect between discussions of 'modularization' in an AIR/Flex application as contrasted with just a plain old Flex application, and maybe there is now enough interest that someone will consider doing that. <o:p></o:p> <div class=MsoNormal> <hr size=2 width=200 style='width:150.0pt' align=left> </div> View/reply at <a href="http://www.adobeforums.com/webx?13@@.59b6ed86/17">How to Test AIR 1.5</a> Replies by email are OK. Use the <a href="http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3">unsubscribe</a> form to cancel your email subscription.<o:p></o:p> </div>

Report · Nov 26, 2008

Alex,

A very welcome, thoughtful post. I would be very happy to provide my thoughts as to what I think would be the answers to your questions. Please let me know via what forum I can offer my 2cents. The little rectangular boxes I find at some sites that seem like they would represent a place for such input to be provided, are not very helpful. Can I just send a PDF file to you somewhere?

To end on a gleeful note heading into that turkey dinner, maybe this ought to be revealed about the author. When I started getting paid to write code, IBM basically had two jobs in a branch office -- systems engineer or salesman. [Don't google it, unless you are willing to try terms like 'autocoder' and '302 Accounting Machine plug-board'.] I loved the systems engineering role, but they paid better if you could sell something, so I had to go on quota and take over some accounts.

One of my accounts was 7-Up, so I scheduled a 'get-to-know-you' lunch for them. We talked a bit before the waiter came to take our orders -- as host, I was last. When the waiter asked, "And what to drink?", I reflexively said "I'll have a Coke."

You might guess that I didn't sell much at 7-Up that year. But, as you can see, coming up on my 5th decade, I've learned some things. I had thought I would just ask where I could send you a .doc file!

Report · Nov 26, 2008

<div class=Section1> color:#1F497D'>If your thoughts are publically consumable, I would encourage posting them (or some of them) on this forum. Then we’d get feedback from others on your thoughts as well. Otherwise, let’s wait for Matt to return from his turkey/crabchip fiesta and he’ll probably gather your thoughts off-list.<o:p></o:p> color:#1F497D'><o:p> </o:p> color:#1F497D'>Me, I don’t have as many years in the business but I’m no spring chicken either. Some of the new college grads we hire have parents my age.<o:p></o:p> color:#1F497D'><o:p> </o:p> <div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'> From:<span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Terry Corbet [mailto:member@adobeforums.com] Sent: Wednesday, November 26, 2008 5:06 PM To: flexsdk-dev@adobeforums.com Subject: Re: How to Test AIR 1.5<o:p></o:p> </div> <o:p> </o:p> A new message was posted by Terry Corbet in Developers -- How to Test AIR 1.5 Alex, A very welcome, thoughtful post. I would be very happy to provide my thoughts as to what I think would be the answers to your questions. Please let me know via what forum I can offer my 2cents. The little rectangular boxes I find at some sites that seem like they would represent a place for such input to be provided, are not very helpful. Can I just send a PDF file to you somewhere? To end on a gleeful note heading into that turkey dinner, maybe this ought to be revealed about the author. When I started getting paid to write code, IBM basically had two jobs in a branch office -- systems engineer or salesman. [Don't google it, unless you are willing to try terms like 'autocoder' and '302 Accounting Machine plug-board'.] I loved the systems engineering role, but they paid better if you could sell something, so I had to go on quota and take over some accounts. One of my accounts was 7-Up, so I scheduled a 'get-to-know-you' lunch for them. We ! talked a bit before the waiter came to take our orders -- as host, I was last. When the waiter asked, "And what to drink?", I reflexively said "I'll have a Coke." You might guess that I didn't sell much at 7-Up that year. But, as you can see, coming up on my 5th decade, I've learned some things. I had thought I would just ask where I could send you a .doc file! <o:p></o:p> <div class=MsoNormal> <hr size=2 width=200 style='width:150.0pt' align=left> </div> View/reply at <a href="http://www.adobeforums.com/webx?13@@.59b6ed86/19">How to Test AIR 1.5</a> Replies by email are OK. Use the <a href="http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3">unsubscribe</a> form to cancel your email subscription.<o:p></o:p> </div>

Report · Nov 27, 2008

On Wednesday 26 Nov 2008, Terry Corbet wrote:
> does require Internet access for some functionality as well as for the
> important steps of initial provisioning and periodic update.

I'm fairly sure the runtime and applications will install on a machine with no
internet connection...

> -- 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.

You mean for the 'allow this site to access my microphone and camera' screen ?

> dependency -- for nice support of framework version management -- causes
> any problem.

The Player must be able to fall back to locally hosted versions, as now,
however.

--
Tom Chiverton
Helping to assertively establish holistic interfaces

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

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.

Report · Nov 28, 2008

OK, I have created a PDF file with thoughts that anyone is welcome to shoot down. I hope Matt or Alex or someone will tell me how to put the document somewhere.

Report · Dec 01, 2008

If you navigate to http://www.adobeforums.com/webx/?13@252.FNGBiqbl0V9@.59b6ed86 I think you can reply to the message and post an attachment (in my web view I see an attachment option underneath the message). Try it out, it's possible that I disabled attachments though so we'll see :-) Matt On 11/28/08 3:33 AM, "Terry Corbet" <member@adobeforums.com> wrote: A new message was posted by Terry Corbet in Developers -- How to Test AIR 1.5 OK, I have created a PDF file with thoughts that anyone is welcome to shoot down. I hope Matt or Alex or someone will tell me how to put the document somewhere. ________________________________ View/reply at How to Test AIR 1.5 <a href=http://www.adobeforums.com/webx?13@@.59b6ed86/22> Replies by email are OK. Use the unsubscribe <a href=http://www.adobeforums.com/webx?280@@.59b6ed86!folder=.3c060fa3> form to cancel your email subscription.

Adobe Community

How to Test AIR 1.5