flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Future of Flex technology
Date Thu, 28 Feb 2013 22:15:12 GMT
Moving this off-line thread with Terry back to the mailing list with his
permission:


On 2/28/13 10:09 AM, "Terry Corbet" <tcorbet@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" <aharui@adobe.com>
> To: "Terry Corbet" <tcorbet@ix.netcom.com>; <jeffry@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" <tcorbet@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


Mime
View raw message