Flash/AIR API AVMGlue

[zwetan]

Hi,

I have numerous private requests about "when will we have a full Flash API in Redtamarin ?"

it's not that I don't want to work on it but it is not in the high priority list

but as users you have a voice, so here what I propose

• a full implementation of the Flash API SWF9
• which will have limitations on many things
  like media: manipulating bitmap, sound, RTMFP protocol, etc.
  (Adobe had 10 years to implement all this ...)
• which could serve as an implementation for a Flash API for FlexJS

Right now my priorities are heavily on the server-side and the C API
but if you, as a user, you think working on a Flash API would be more important
you can signal it here, a "+1" is enough, any other comments also welcome

If I see enough ppl wanting this, then I would setup a kickstarter (or something else)
which will basically set a price and a time deadline with the exact
detail of what you would get

Personally, I'm not a big fan of Kickstarter or Patreon or whatever when it is related to
open source projects, but if I see a lot of ppl ready to pay few bucks
(think closer to $30 than $1) to get a "product" sooner than later
then OK I can take the time to work on it well... sooner

Simply ignore this if you can wait or not interested

[zwetan]

for the FlexJS part

once you have something like URLLoader implemented in AS3 with low level function calls
I think it is just a matter of porting the implementation to JS with different JS API like Node.js, Browser client-side, etc. a bit of what StageXL for Dart

I could be wrong, but the idea is "hey we got an open source implementation of an API we love, let's just port it to other places", could be FlexJS, Java, .NET, etc.

[ajwfrost]

Are you thinking of including graphical support then? Or just using the Flash APIs that make sense for a server-side target?
There are a lot of APIs from Flash Platform that it would be useful to have, but also a lot that I think aren't so relevant... Tricky to get a decent list together!

[zwetan]

Are you thinking of including graphical support then?

at the API level, that means be abel to use the code, read the code
call methods etc. without having the runtime complaining about something missing

think the display list implementation of Stage3D but for the CLI
it feels like the display but in the case of the CLI it does not render anything on screen
(that would be implementing an actual Flash Player and this is a non-goal)

Or just using the Flash APIs that make sense for a server-side target?

yes more in those lines, so dev can reuse libraries, source code
without Redtamarin runtime complaining
eg. class Main extends Sprite

There are a lot of APIs from Flash Platform that it would be useful to have, but also a lot that I think aren't so relevant... Tricky to get a decent list together!

I mentioned "Flash API SWF9", that means Flash Player v9.0 / AIR v1.0 API
and what make sense or is relevant can vary a lot depending on ppl

some things just need time to be implemented, others are much more complicated
but instead of listing what is possible or not let's see the amount of interest

to be honest I mainly do that to shut down ppl who ask Stage3D rendering server-side
by private emails as if it was an easy thing to implement over the week-end ...

[ajwfrost]

Okay that sounds good. To get it all started I believe it's possible to create all the API stubs by decomposing the playerglobal/airglobal swc/abc files.. Think I looked into that a couple of years ago :-)

[zwetan]

already done ;)

[zwetan]

update:
not a question or a kickstarter anymore

1. AVMGlue API will be implemented after an async/events solution is implemented
2. some implementations will happen first in betalib
3. some other have to happen inside redtamarin code base as they need native API implementations
4. then when the API coverage will be close to 100% everything will be merged back into redtamarin

versioning will be:
"Flash API SWF9", that means Flash Player v9.0 / AIR v1.0 API
anything above SWF9 will be considered a "lucky bonus" and/or unstable

100% means all the SWF9 API but not necessary a complete implementation
anything UI will be a mock, eg. don't expect to be able to display anything

a configuration system will allow to hook your own code in some part of the API
for example: "behave like Flash Player" vs "behave like AIR"
and custom things like "behave like Flash Player but remove/replace such and such behaviours"
like accessing the file system etc.

[zwetan]

some thing to focus on:

be able to compile code from "Flash Builder", "Flex SDK" etc.
using "redtamarin.swc" acting as "playerglobal.swc"
and use the generated SWF with the redtamarin runtimes redshell

some one should be able to setup very quickly an AS3 project in Flash Builder
be able to reuse pre-existing SWC libraries, compile and get a SWF
that can run "as is" with redshell

[zwetan]

some part fo the AVMGlue API will be implemented out of the Redtamarin code base as part of the avmglue project.

Reason:
AVMGlue API is a convenience for dev used to work with Flash/AIR API
most of it can be implemented with AS3 and the CLIB and/or RNLIB
so we can see it as an "external library" instead of an "internal library"
that need to be embedded or available at all time.

eg. load( "avmglue.abc" ); is good enough

[zwetan]

AVMGlue API is currently being implemented
because we have an async/events solution

some details

• some implementations will happen first in betalib
  we did not do that to favour a faster test/release cycle
  cons: not public, pros: it goes faster
• some other have to happen inside redtamarin code base as they need native API implementations
  we adopted a different approach to native API implementations
  we only provide a native AVMGlue class if absolutely necessary
  otherwise the implementation is done in AS3 with the support of the C API
• some part fo the AVMGlue API will be implemented out of the Redtamarin code base as part of the avmglue project.
  nope, finally AVMGlue will be fully embedded into Redtamarin runtimes
• high focus on the documentation
  we target 100% AS3LCR coverage
  and try to document above and beyond (things missing in AS3LCR, corrections, holes, etc.)
  also document differences specific to Redtamarin

the goal is to be 100% API compatible
if your code was working in FLash or AIR then it should run inside Redtamarin
but with some limitations

• no graphic rendering (as always)
• some API will require to run in asynchronous mode
  eg. Runtime.goAsync()
• we will follow the logic of Workers already existing in Flash/AIR
  see Concurrency in Flash Player 11.5 (Web Archive)
• we will also follow the logic of capabilities of different profiles
  see Building Adobe AIR Applications / Device profiles
  on top of the existing profiles: desktop, extendedDesktop, mobileDevice, extendedMobileDevice
  we add our own custom profile server
  for ex: if with the Accelerometer class
  desktop and extendedDesktop are not supported
  and mobileDevice need to "Check"
  the server profile is also not supported

eg.

Class or Feature	server	desktop	extendedDesktop	mobileDevice
Accelerometer (Accelerometer.isSupported)	No	No	No	Check
Accessibility (Capabilities.hasAccessibility)	No	Yes	Yes	No
Acoustic echo cancelation (Microphone.getEnhancedMicrophone())	No	Yes	Yes	No
ActionScript 2	No	Yes	Yes	No
CacheAsBitmap matrix	No	No	No	Yes
etc.

• all AVMGlue API will be implemented, at the very worst as a Stub
  the definition exists, it does not break existing source code, but the functionality is not available (eg. it provides No Operation NO-OP)

• later on, some functionalities will be fully implemented (still focus on the CLI)
  for ex:
  if for now you could use flash.net.Socket with the condition to use it in asynchronous mode
  eg. you HAVE TO call Runtime.goAsync(), but flash.net.SecureSocket is available only as a stub (eg. we do not have SSL/TLS functionalities yet)
  later on, maybe in redtamarin 0.5.0 flash.net.SecureSocket could be fully implemented
  eg. if( Runtime.equals("0.5") ) { trace( "SecureSocket supported" ) }

• in the documentation we will mark clearly what need to use sync/async
  what is a stub or not, etc.