Adobe AIR SDK can be thought of as a lighter alternative to browsers for developing multi-media apps. Actually Adobe AIR SDK is maintained by Samsung HARMAN. For those who don't yet know, AIR SDK is built with Flash Player. Adobe AIR SDK does not yet support publishing apps to web browsers, but HARMAN does plan to allow so.
ActionScript code is compiled to its own bytecode (ABC) by the SDK's integrated compiler (amxmlc or acompc).
If it is of interest to compile Rust to AVM or package as SWF, I saw something that might be useful, wasm2swf, but this project needs more ellaboration to allow compiling Rust to SWF. I'm noob when it comes to low-level details, such as adapting the systems API to target SWF, but there was a project called Crossbridge that did something similiar with C/C++.
Otherwise, maybe is it possible to use solely the Adobe AIR SDK runtime from Rust (say, DLL and shared objects)?
About HARMAN maintainance
Until Adobe AIR was given to HARMAN, it was totally free if I recall well. Now, the free plan shows a splash screen.
I think that if you want to work on it as a backend, and could support it at the appropriate tier level as described here, that it would be accepted (I'm not a part of any rust team, so I do not speak for any part of rust!). However, I know that the rust teams (all of them) are quite stretched as it is, so adding a whole new target won't be very high on the priority list.
Why waste effort on legacy technology? What's the use case?
It took a concentrated effort on an internet scale over a decade to get rid of flash. And good riddance given the amount of security vulnerabilities and breaches caused by it.
Rust's selling pitch is about security and safety. Why would it want to associate itself with one of the most notoriously unsafe pieces of technology we had?
I understand that some enterprises are either very slow to migrate or simply don't have a business case to invest money to migrate some of their existing stuff away from it. Fair enough. But why start any new green field projects with this tech?
The reason I got interested in this topic is because Adobe AIR API covers many things the web browser API covers, and is more efficient in general (lightweight).
But I don't think Adobe AIR is good at all, it's just that it's better than using a browser runtime uneccessarily for normal apps. I think there doesn't exist a SDK for Rust in that sense; so the only one I know is Adobe AIR SDK for now.
There's SFML, but it seems legacy as well or not as good as AIR SDK.
Using the Adobe Air APIs / SDK is not the same as using the Adobe Air runtime.
Your original question is about the latter only - compiling to wasm and converting that to run on the Adobe runtime. This gives you no benefit really, just use a wasm/wasi runtime environment. All major browsers support wasm but also there are standalone ones as well, actually written in Rust!
Using the actual Air SDK APIs from rust would require to expose FFI bindings to rust code and that's an additional major undertaking. And why would you even want to do that? Rust already has a standard library and a rich ecosystem of crates that should provide all the APIs needed.
If something is missing, it is better to fill those gaps in native Rust imo.
I think you need to do a lot more research and come up with a strong and well defined motivation before asking for changes or additions to the language.
If you want to discuss your use case and how to use Rust for it than you can post to the users forum.
It looks like you didn't understand my words. Adobe AIR SDK allows you to compile ActionScript sources into SWF/SWC, and then also allows packaging SWF into native executable or installer for Windows and other OS (via its adt tool). There does exist a Adobe AIR runtime that can be installed like the Flash Player, but I was not talking about this one.
While I type here, I may sometimes omit the "SDK" part to avoid repetition.
I'm quite familiar with flash and the AIR runtime. I'm still not really sure what you're proposing as the value proposition.
The main one I could think of is if you have an existing codebase or workflow that emits to AIR and you want to extend the native functionality: then I can maybe see it. But honestly I'd rather see the other way around and have that content be built as a library (.swc) and have the ability to link against that with LLVM, basically be able to ahead of time compile the bytecode.
You would still need to provide implementations of all the flash and AIR apis used, but I don't actually think that's too scary? Probably about the effort of a PDF renderer (given a parser): the first 90% is pretty straightforward, tedious work. Honestly, it's probably better to have a clean implementation at this point.
In this case I was mostly curious if Rust could fit to be used with AIR, I don't want to port anything from AIR to Rust. There seems like there's not anything like AIR SDK on crates.io yet, instead there is web browser API. If not browser API, then there are different crates for possibly building a SDK, or one can choose to use several crates instead of a single crate (in this case, an Adobe AIR SDK-like API).
Yes, rust and cargo are the AIR SDK. The functionality provided by AIR is that needed to support building desktop applications, in addition to the existing flash functionality: filesystem access, networking and the like, much of this is the Rust standard library.
There's a lot of effort going on to get the GUI side implemented, which you can browse at areweguiyet.com. Some are a bit more Flash-ey than others, but none are really the same sort of content-first API that Flash's grew out of. There's still a gap there, but fortunately it doesn't need to wait on the compiler team to implement anything: anyone could build it.