With Adobe obviously focusing on improving the runtime for the gaming stuff, that in theory should be good for Flex if the new features can be utilized by class updates in the framework right? I'm pretty knowledgeable and familiar with Actionscript as it has matured over the years, but not as much with the inner workings of the Flex source, but from my understanding hopefully I'm on the right track there.
With Flex being focused primarily on data driven apps, as opposed to custom applications (games) would it be possible to create some new Flex components that utilize Stage3D? I know there are some simple controls that have been built using starling, feathers UI, but I imagine the same technique used there could be applied to Flex components. Also maybe there could be some Flex components related more to the 3D context itself. My understanding is that the display list which is the normal 2D graphic pipeline sits on top of an underlying 3D context that is initialized but maybe Flex could be useful in adding some interoperability between the two. So possibly a set of components that renders out to the 3D stage as opposed to the display list. That might be a little too abstract of a description but it would be great if there were not only components to create stage3D contexts in a Flex application (I think that you are supposed to be able to have multiple contexts in a single application), but also to be able to pass in something to a context via a flex component. So the component would initialize the context and make sure it's visible and size it etc, but then you could nest things in the component in order to control the innards of the context itself. Just a few thoughts, but these are the kinds of things that I imagine in terms of Flex maybe being able to utilize new features from the runtime as they come out, besides the cross compiling work. Thanks, David Hertenstein Lead Developer .idea T. 214.529.0668 E. david.hertenst...@idea.com www.idea.com -----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: Thursday, February 28, 2013 4:15 PM To: Terry Corbet; jef...@dot-com-it.com; users@flex.apache.org Cc: Harbs Subject: Re: Future of Flex technology Moving this off-line thread with Terry back to the mailing list with his permission: On 2/28/13 10:09 AM, "Terry Corbet" <tcor...@ix.netcom.com> wrote: > > B. Someone MUST get out in front of the ever-changing landscape > instead of letting those of us who DO NOT PLAN TO WRITE GAMES have to > guess or imagine what the path will be to being able to continue to > develop/enhance our products that right now are teetering between > resources you control and resources that Adobe controls. Compilation > resources AND runtime resources are both required to get the desired > results. If Thibault gets Adobe to add exciting new functionality X > to his AIR SDK, it most assuredly will only be accessible via > Actionscript and if the way to implement exciting new functionality X > is via changes/enhancements to ASC2, when/where/how, precisely, should > folks dependent upon your latest/greatest Spark-Based Accordian > component expect to be able to roll it out in a new release of their own > applications with shiney new functionality X? If an AIR SDK gets new ActionScript functionality, we should be able to access it from Adobe Flex. I don't expect changes to the language that only the ASC2 compiler can handle, and minor changes to ASC2 we can probably get donated. But keep in mind, those changes will be focused on Gaming and therefore Stage3D, and are less likely to be relevant to Flex apps. > > C. I am certain that you have thought about those issues, but > if your own private preference is to want to be able to offer exciting > new functionality X, in a browser using whatever the evolving > standards body offers in HTML/CSS/Javascript, it leaves the impression > that being able to do that with respect to desktop applications > dependent upon the Adobe Integrated Runtime is NOT a priority, as > seems confirmed by the fact that Gordon is only on loan one day per > week, and there is apparently no published task list of which specific > MXML components have already been tested, which specific MXML > components properly compile, which specific MXML components fail, and > which specific MXML components have not even been looked at because no one in > the community has sent him a test case. IMO, MXML handling in Falcon is not yet at the point where a work list is even prudent. It will take longer to try to describe everything that is not yet working than to just sit down and try to fix it. Eventually, we will try to make the entire Mustella suite pass with Falcon, but right now, it can't even compile the SDK's checkintest. > > D. Blogs, tweets and mailing lists are NOT the way that > products are managed. If either your job description as stated by > Apache, or your job description, as specified by your being on loan > from Adobe does not include Product Mangement, and is circumscribed by > the usual job description for Project Management, I think that passing > my particular observations on to the next higher level in the chain of > command would be best. If Product Management is in your portfolio, > then my suggestion is that you find an appropriate > publishing/dissemination mechanism for getting the message out to the > marketplace. There is no chain-of-command in Apache per-se. The PMC is tasked with specific processes regarding code releases and new members, but code-wise, the committers are all on the same level, and there are no traditional product roles like Product Management, Project Management, Marketing, Quality Assurance, Development Management, etc. We bought into this culture by becoming an Apache project. I agree that Apache Flex could do better in outbound messaging, but that is outside my area, and Adobe is not going to offer up people to help (I asked). Right now my main goal is to get the JS prototype to a point where I think it is worth making more noise about and then start making noise. If you have thoughts on what we should be saying about the current Apache Flex, please offer it up. Keep in mind that Apache Flex mostly consists of volunteers: very few folks get to spend all day on it like I do, so the project has generally agreed to avoid making promises about the future. So if there is a message about what we have already done that needs to get out and you have a suggestion about how to get that out, I am eager to hear it. > > Best regards, > > Terry Corbet > > ----- Original Message ----- > From: "Alex Harui" <aha...@adobe.com> > To: "Terry Corbet" <tcor...@ix.netcom.com>; <jef...@dot-com-it.com> > Sent: February 28, 2013 09:35 AM > Subject: Re: Future of Flex technology > > > Hi Terry, > > Please re-post this on the mailing list so I can clear up your > misunderstandings there and probably help out a bunch of folks who > also have the same misunderstandings. > > Thanks, > -Alex > > On 2/28/13 9:18 AM, "Terry Corbet" <tcor...@ix.netcom.com> wrote: > >> Jeff, >> >> Taking this offline since flame-throwing was not my reason for >> pointing out that Alex's enthusiasm for cross-compiling to >> HTML/CSS/Javascript causes me a good deal of concern. >> >> Yes, the problem is that we cannot, today, successfully adapt/enhance >> our AIR applcations on an on-going basis the way we could when Adobe >> owned the SDK and provided the releases. If that's true, we need to fix that in Apache Flex. >> >> A. What version of Flash and AIR does the latest release of the >> Apache Flex SDK support? I could be wrong, because it is so out of >> date that I have not bothered to try it, but when I checked a couple >> of weeks ago the answers >> were: Flash 11.2 and AIR 3.4. That is where we've focused or testing, but, unlike Adobe Flex, Apache Flex provides scripts to overlay newer or older Flash and AIR SDKs and will support you if you run into issues doing so. >> >> B. My AIR apps [about 10 of them] were upgraded to AIR3.6 within a >> couple of hours of when that became the most current AIR runtime last >> week. That was only possible by layering the Adobe AIR SDK on top of >> the old Adober Flex SDK [otherwise known as 23201B]. So what you >> have to work with today is about a year-old version of the Flex >> framework with the most current AIR framework. Adobe decided to re-package the default download for the AIR SDK starting with 3.6 to include the ASC2 compiler instead of the Flex SDK. It makes sense in that it better aligns with Adobe's direction even though it creates a bump in the road for Apache Flex. These kinds of issues are probably going to be a fact-of-life for Apache Flex going forward. However, Adobe did make a package for Flex customers (yes, they still support Flex) which is in the fine print below the download buttons where it says: Note : Flex users will need to download the original AIR SDK without the new compiler. Mac Windows. In theory, if you use those kits, your overlay workflow should continue to work. >> >> C. Now go look to see what AIR SDK you can get from Adobe going >> forward -- it is ONLY the one using the new compilier. The old >> compiler is no longer part of the download. See my response abovle. >> So, when the beta for AIR3.7 or 4.x, or whatever, >> next starts getting trumpeted by the Game-driven Thibault, where will that >> leave us? It will leave us unable to layer AIR enhancements on the >> Apache >> version of the Flex SDK until Gordon can make the new compiler work with >> our >> MXML content. It is not just Gordon who is responsible for Falcon. >> Or, it they come up with a mashup that uses the existing >> compiler, it means we don't get the beneifts of the enhancements built >> into >> Falcon/ASC2. If you don't think that inline code generation speeds things >> up, it is probably because you don't have an application that performas a >> lot of CPU-intensive work. Falcon will eventually replace MXMLC at Apache Flex. >> If you don't think that being able to push U/I >> functionality off to the GPU is key, it is probably because you have not >> had >> any reason to invest in 3D for your applications. Stage3D has some issues around accessibility which I believe is still important to many Flex customers. In my new framework, we're going to find out if Stage3D really is key to UI performance or if the old framework was just running too much AS before the renderer got its chance. >> >> D. A point I was trying to make is the one that often gets translated to >> short-hand as: "Adobe Marketing Bad, Apache Engineering Good". Any >> robust >> technology needs good engineering and good marketing. I am not slighting >> the Apache engineering, but ask yourself who, over this past year-and-half >> has stepped up to the marketing responsibility for the Apache Flex SDK? Apache Flex is mostly made up of volunteers. Nobody owns the marketing responsibility. But Nick brought us a new website and Scott created a press release. Sure we could use more help, but that the nature of working with volunteers. >> Is >> that Alex's job description, probably not, but then whose job description >> is >> it? Go look at the noisey guys from Spoon. Are they the marketeers? If >> so, why is their latest blog posting from December? Who writes the white >> papers, who sets the vision for the Apache Flex SDK project when Adobe is >> considering ActionScriptNext with no backwards compatibility. Thank >> goodness, that got killed, but who is looking at Actionscript growth, who >> is >> looking at Spark components that use the GPU? There is not, as best I can >> tell, a product manager, and without that, there is no reason to feel >> confident that the necessary resources and priorities will be applied to >> keeping our favorite development tools/libraries/frameworks current. >> Worse, >> if Alex is the de facto product manager, he has clearly [in any number of >> postings] let it be known that he is betting on cross-compilation to >> HTML/CSS/Javascript NOT betting on being able to compile to the latest >> verstion of the Adobe-controlled AIR runtime. This was answered above. There are no traditional roles in Apache Flex or Apache projects in general. We are looking for volunteers to help out, mostly in their spare time. My goal for this year is to find at least one major Apache Flex customer (who will hopefully also a major Adobe customer) that will either supply resources to assist in these non-coding roles, or influence Adobe to supply more resources. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
