I'd like to complete my thoughts:
Flex is a framework, not a runtime, not a language (except for MXML maybe).
The strenght of flex is the features, the architecture, the components, etc.
So i see 3 area of work to ensure a bright future for flex as a multi
target SDK.
1- the modularity of the architecture:
Everyone seems to agree on that one. For multi target strategy, we
need to be able to disconnect some parts of the framework unsupported by
some specific targets.
As we need to be able to have a lightweight SDK when we don't use
every features of it.
The break of UIComponent seems also needed to be able to more
easely change the rendering layer. Maybe i am wrong?
Did some work or discussions have already been done on this? as it
seems there is a consensus on this point.
2- rendering layer.
In a multi target strategy, we cant rely on the flash player
Display list rendering anymore.
We need to target new layers like straling2D? openGLES, HTML5 Canvas...
What does it mean to do so exactly? what is the amount of work?
Some research has been done to try to target starling2D, what is
the state of it? what are the remaining issues?
3- the transcompilation, or the trans coding of the framework.
as targets have different languages, and some have interpreted one,
and some targets don't allow plugins, we can't rely on a VM anymore.
the sdk has to be transcompiled to several bytecodes or interpreted
languages.
Falcon will be very helpfull for that.
The first step already undergo is the MXML support, FalconJS is
already on his way to be donated. let's see what the next step will be.
Next runtime bytecode?
Questions are:
- Do we have a clear view of what tie the Flex SDK to the Adobe's
runtime, and need to be handled for a multi target strategy? in the
rendering layer but also everything else?
If we identify clearly what are the difficult points, it would be more
easy to take decisions, of what can be dropped (like e4x) and what need
a solution.
It seems that the work on FalconJS has already given a good start on
such information.
Can we have a clear list of such issues?
- How difficult is it to change the rendering layer? Is the current sdk
architecture a break to make it easely possible to do? Do we have to
rewrite from scratch a Display list system without all the optimization
that Adobe put on the flash player one? Does starling2D give a good
solution for that purpose?
- Is it realistic to think about using Falcon to change the codebase
language of flex to another? I mean to transform flex from an AS3
framework to another language framework of the community choice, like
Dart, or C# or whatever. And be able to work on this generated code, not
only for transcompilation purposes.
I mean we may need it in a near future to ensure a successfull multi
target strategy. (im still not sure of this need though but im trying to
see if its a realistic option to keep in mind)
Its still more realistic than talinkg about starting a new framework
from scratch.
As a conclusion:
There were several discussions about the multi target essence of flex,
and HTML5 target especially. but no conclusion has been given. no clear
view of what it means to change target and get out of flash player runtime.
Lets use this flash player Next subject to clarify it.
I think that getting a better understanding of what commiters have in
mind regarding those subsjects, would give away some of the frustration
(see 'Is Apache model killing this project?' discussion). I'm not
talking about roadmap, but at least a vision of what flex future should
be, and what it needs to get there.
And giving more precise informations of what the difficult points are,
what is possible and what is not, would get the whole subject broke in
several smaller projects, in which some little groups (or even
individuals) of the community could get confident enough to work on it.
Flex is a big beast, so the answer "do it yourself and we will check it
later" will get us anywhere. We'r not talking about a new component, but
big architectural choices and changes.
IMO the community needs some clarification, and some smaller issues,
smaller projects, but included in a global consistent strategy, to be
able to contribute.
That was also my answer to the 'Is Apache model killing this project?'
discussion.
Thanks
Regards,
Le 19/10/2012 14:59, sébastien Paturel a écrit :
Thanks Gordon for asking about the nature of Flex.
Flex is a RIA sdk and not a gaming SDK, ok thats quite obvious.
But flex must be multiscreen ! and if flex don't run on all screen it
has no future!
What has put Flex in a difficult position last month is the fact that
HTML5 could not be targetted!
What has kept Flex alive is to be able to create apps for iOS and
Android with the same mature framework.
And what can give a bright future to Flex is to be able to target as
much screens as possible, again, including HTML5.
So lets define a multiscreen strategy here!
Today:
Flex is multiscreen because it runs on Adobe's Flashplayer and AIR.
One of its big strenght is to be able to create apps for Desktops
(starting from flash player 10 which has unbeatable ubiquity thanks to
the monopoly of flash player on the video streaming area), smartphones
and tablets, including iOs AND android.
but it can't run on HTML5. Its not a big deal yet because HTML5 is not
mature enough (performances) and the user usage is not much on the
webapp area yet, so native apps is the place to be for now.
It can't target linux well since AIR runtime will not target it
anymore, and flash player is not quite stable. Its sad but its not big
deal as an economic point of view, as theres not much users on it.
Thats what makes Flex still a rationnaly good solution nowadays, even
in an HTML5 hype world.
Tomorrow:
If there is new mobile hardwares smartphones and tablets, Adobe will
probably target it with its runtimes, but according to its new
strategic shift it will be with the new gaming runtime only!
So flex won't run on those new hardwares even being based on Adobes
runtimes, if we do not port the framework to this new runtime
architecture! Am i wrong?
It would kill Flex for mobile, as a viable commercial solution.
So if the port to new Adobe runtime is a manageable amount of work
(threw starling2D), i think we should do it for this reason.
If we need to change architecture of flex sdk for it (more modularity
and break the UIComponent as everyone wants to), lets start with it
anyway.
In that case Flex would still rely on Adobes runtimes for multiscreen,
but being inline with the new Adobe strategic shift so it would give
the project more time to be able to run on Adobe's free runtimes.
And being based on a stage3D renderer, would make the future shift to
openGLES more easy. Am i wrong?
Near future:
IMO the goal is that:
Flex target openGLES and native runtimes of all mobile hardwares. My
personnal dream is to be able to target all screens including smart
TVs and gaming consoles (but for RIA apps dev)
Flex target HTML5 which has become mature and viable for serious RIA.
In conclusion,
The first priority for flex IMO is to stay multiscreen.
targetting HTML5 is big priority but in a long term.
targetting new coming mobile hardwares is big priority in short term!
The final questions are:
is it really a more rapid solution to target Next Adobe's runtime as a
first step before being able to target any new mobile native runtimes
(threw openGLES directly) or not?
And what we need to change first in the framework to make it possible?
Do flex need a language port to stay multiscreen? stay with AS3? AS4?
Dart? Haxe? etc.
I'm eager to read your thoughts and arguments, pro and against.
Thanks
Le 19/10/2012 01:28, Gordon Smith a écrit :
Yes, the community has to figure out what the essence of Flex really
is. To me, it's an rapid-development application framework, the
combination of a procedural language with a declarative language, and
a widely-deployed runtime that can support RIAs. The runtime of the
future for RIAs seems to be native code for mobile devices and
HTML/Javascript for browser apps. The best procedural language is
anything that can be compiled to these runtimes. MXML is a perfectly
good declarative language for UIs.
- Gordon
-----Original Message-----
From: Michael A. Labriola [mailto:labri...@digitalprimates.net]
Sent: Thursday, October 18, 2012 4:07 PM
To: flex-dev@incubator.apache.org
Subject: RE: ASC 2.0 and Falcon
PS I don't think Apache Flex needs to stand for what Flex is today
though, and this is where innovation in the future needs to happen
in this project.
+65535
