2017 Going Rogue


#1

In our industry a lot of things get picked up because of trend and other hype,
and then generate popularity: a kind of self feeding machine which make someone
use a tech just because other people use this tech, so that must be the right choice, right?.

When your own tech, your baby, is not popular (at all) you can either try very hard
to convince others to migrate to your brand shiny new toy, and if you are heavy enough
it might work (and not work if you’re just a tiny little ant).

Or you can rebel and say “Nope”.

What it is to go rogue?

adjective
11. no longer obedient, belonging, or accepted
and hence not controllable or answerable; renegade:

No longer obey what the whole industry is feeding you: “do this, use that and shut up”.

You basically cheat the system (“fuck the system!”) by not following its rules.

Is it crazy? maybe :slight_smile:

But the only way to re-invent a system that no longer fit you, to truly think out of the box,
is to go build stuff outside of this system, to do things really differently.

When people tell me “ActionScript 3 is dead because Flash is dead”,
that’s why I say things like “No, ActionScript 3 is now a secret weapon”.

And it’s not only ActionScript 3, it is also the AVM2, the toolchain, the compilers, etc.
Those form a great tech stack base to build uppon.

And that’s why Redtamarin exists in a space where ActionScript 3 was not really expected or even wanted.

The command-line, the server-side, and beyond …
Where no one control us and not forced to answer to anybody.

Free to build and create.

It is a “secret” because nobody want it or use it, it’s not “à la mode”;
and it is a “weapon” because you can still build great stuff with it,
and do so, I believe, faster and better (also stronger and harder).

Create?

From the very beginning it has been about that: building software with ActionScript 3.

To me the perfect hybrid language which can go as “dirty” as you need it to be,
and at the same time go as “structured” and “organised” as wanted by those … more complicated things.

So during 2016, you didn’t see a lot of things being created with Redtamarin,
I know I know, you see no activity on an open source project, and you are already jumping to conclusion:
“this project must be dead or abandoned”.

Nope, that is called “stealthy mode” :smiley:

The last 11 months of “inactivity” is just the public stuff you can see on Github,
Redtamarin is developed via subversion on private servers which then are mirrored later.

There have been tons of commits and changes, you just don’t see them yet.

Because?
It’s not ready yet, I work on the trunk, I publish when the trunk is stable.

But those changes are not that important (even if there are massive and coming in the 0.4.2 release),
what matters is by using Redtamarin on a daily basis I kept creating tools and other utilities,
I kept automating stuff (the only way to survive when you are a “one man shop”), so here few examples:

  • When working on building some complex REST API
    I needed a way to test the input and output of those API
    using curl and bash was OK for a start but failed at more complex scenarios
    those API are connected to different IoT and other sensor devices
    so I needed a way to emulate those and for that I built “virtual sensors”
    as command-line tools built with Redtamarin so I could emulate different
    protocols and behaviours for “presence detected”, “lights are on/off”, etc.

  • When working on servers I needed to automate many things
    like the listing/creation/setup/backup/etc. of http/ftp/svn/mail/database/etc.
    again I could have used bash but I needed to deal with many entities and hierarchies
    so for that I used as3shebang to manage many domain name, many virtual hosts,
    many ftp user accounts, many svn account, etc. for many organisations and customers
    all those AS3 shell scripts have been a real time saver
    and “cherry on the cake” I can now easily migrate them to proper command-line exe

  • inbetween the servers automation and command-line tools
    I needed “services that monitor and react on stuff”
    so I built daemons for Linux that read logs, find specific stuff with regexp
    and act uppon it by telling the system to open/close/update other stuff
    I built all that with an internal beta of redtamarin 0.4.2 for the daemon part
    and another command-line tool to manage it via sockets,
    pretty efficient, I like it and I can deploy/update it in seconds

Now in 2017, the goal is to publish some of those tools in a more professional manner,
because “wow that’s really useful” or “hey it does save a lot of time to do it like that”
and yeah “looky here, it’s build with redtamarin and it is easy to use” :slight_smile: .

Which is mainly why I operated in the shadows, I know the stuff is good
but I did not want to come up and present half baked shit
“oh look you can make a socket connection!” … no, that’s too easy.

What I want is to show you how to build a chat server,
or how to build a custom interactive shell like what’s Github is doing,
and tell you that both take only 20 lines or so of ActionScript 3.

That’s a bit harder to pull off but much more interesting imho.

Build and create useful tools that do useful stuff and make all that easy.

I don’t get too much into the details of which tools for what use
but 2017 should be an interesting year for Redtamarin tooling ;).

Workflow

Redtamarin is a complex beast to work with, it’s not only the C/C++ parts,
it is also the building/writing/testing of those parts when those parts are all
moving at the same time and so on different operating systems.

At first I was using a lot of Virtual Machines but those require a lot of RAM,
so when you’re stuck with 16GB of RAM you soon reach the limits of what you can do.

Then I moved to external hardware to provide “little island” of testing with
their own ressources (CPU and 8GB RAM), which is not that bad but also limited
in some ways.

So if your automation does not provide all the power and speed you need,
here my advice: keep automating, keep making your workflow better.

In order to do that I needed more power to be able to do many stuff in parallels,
and I also needed much more screen space specifically to be able to switch
between many different projects with long not too easy to edit source codes.

My answer to that for now is a beefy hackintosh with 64GB RAM and 3 monitors.

Yep, it is an investment, but it was so much worth it, I can now edit a dozen
code projects on virtual spaces (that’s 3x 12 = 36 screens) using less than 32GB of RAM
and at the same time span many VM with the other 32GB of RAM, while I still
remote run/launch/compile stuff on the external hardware (which now include a mac mini with 16GB of RAM).

With that I can now write and compile C/C++ in less than 2 minutes iterations,
I can test and experiment more and do it faster.

The best part is I can switch between projects (work related or open source related)
in a split second with not too much damage or latency in the “coding flow”.

I have plans, I organise stuff, but sometimes you need to go with your instinct,
and being able to jump into a project just to test an idea that came up few minutes earlier
is priceless to say the least.

For example with the 0.4.2 release of Redtamarin I had planed an API for sockets,
which is basically “programming stuff for input/output over the wire”,
but then I realised I could do also something much basic and usefull as
“programming stuff for input/output, period” and that how the streams API were added.

All that new hardware goodness for what?
For the big complicated stuff to come into Redtamarin.

I now have the need to work on branches, and that means being able to add and explore
big span of C/C++/AS3 code on “experimental” implementations, in parallel of what
I’m already doing with Redtamarin.

Using subversion, working on the trunk for the main implementation, and working
on branches for other implementations, and merging if all goes well, is a classic
not too hard thing to do.

But when you do it in parallel and it’s based on C/C++, believe me you need that
kind of hardware power, it’s not overkill, far from it.

This whole new workflow should now allow me to provide much more regular public updates,
because I’m simply not stuck on experimenting big stuff in the trunk.

It should also highly influence the amount of tools and other utilities I can put
“out there” for public consumption.

The Discovery of the Obvious

An open source project if made of ups and downs, and sometimes among all that mess
you get lucky without really realising it right away.

I remember, it really started with v0.2.5, it made sense to have this C package,
to have the C headers like stdlib.h as package names eg. C.stdlib.\*,
but at that time I was completely oblvious on how much this would influence
the design of the API.

It shaped up more with v0.3, then v0.4 it’s really where I saw how much important
it was to have this low-level C API.

I was following a sound plan: write as less as possible of native C/C++,
because I was not that good with it in the first place, because it was so slow
and error prone to implement, because once you got that tiny bit of native functionality
you can really glue “all the rest” with ActionScript 3.

And that was falling into place with the 3 layers of API: C API, Redtamarin Native API,
and AVMGlue API (that’s Flash/AIR API implementation).

So yeah I had a “big picture” but it was still a bit blurry on some places,
now it’s perfeclty clear and fluid.

The C API is the most important native API of Redtamarin, it is the solid flat ground
on which you build everything else.

But it is complicated, not only the native implementations, but also using it in AS3.
Because to really use all its powerfull features you need to know both C and AS3,
which is not something that everyone want to mess with.

That said, this C API is here to stay and to get better and better with time,
honestly it is already quite good, but I still have ways where I know I can improve it.

Proto 042

About release 0.4.2 in relation to the C API, here what happen when you decide
to use a powerful API to really get into implementing the “hard” stuff.

Bare with me, imagine for a minute you are developing software in C++,
you would rely on this C functionalities to implement your classes and
build the structures and other logics you need.

The problem is you have to know and compile C/C++.
Those are great tools but you can easily burn yourself with them.

Now, let’s do it the Redtamarin way, you have the C API and the whole
ActionScritp 3 language to build your software.

Granted, using the C API “as is” is hard, but once you got few utilities
as AS3 classes, it gets easier and easier, and you can build uppon those,
and grow your software more and more.

And with the same logic of the Flash or AIR API, it is cross-platform “by default”,
once you know how to use a class to work with sockets, you can reuse it anywhere
without really thinking twice about it.

That’s what proto042 is about: it shows how you can use the Redtamarin C API
to build such utilitarian API, such as StreamClient to work with TCP streams,
or DatagramClient to work with UDP datagrams, etc.

You will notice that the Redtamarin shell.network.StreamClient is very close
to something you already know flash.net.Socket, and same for the other one
shell.network.DatagramClient is pretty similar to flash.net.DatagramSocket.

Sure you will need a bit of documentation and other examples to get going,
but it is much more easy to grab than to do it all with the C API.

Some people will just use those API “as is” and build more stuff with it (I hope),
some others will go into the implementations details and have the same revelation I had
“Holly shit, you can do all that with the C API ?!?”, yes you can :p.

So those new set of API are not a perfect and flawless implementation, if used enough
I’m pretty sure some bugs will get discovered (and fixed) but they are here for that:
make things easier.

Once you got something like a FileSystem class and a StreamServer class,
implementing your own SimpleHTTPServer (like Python) is one easy step away.

On my side I struggled a lot to get those API implementations “right”,
mainly because I wanted those API to be embedded by default in the runtime
and not be an external library that you have to load, so yeah it made things
a bit more complicated to develop and to test, but so much worth it.

It’s not a huge API, it’s just streams and sockets but it should allow
to build much advanced and better things.

The Next Stuff to Come

Just because of release 0.4.2 (which embed proto042, everyone is following?)
all the default tools from redshell, to redbean, to as3shebang and other libraries
like httplib etc… will be updated and improved.

The next focus on the C API will be about processes, how to control them, kill them,
read their input and output at the same time, etc.

You will see also implementations for users management: creating user, creating groups,
adding user to a group, changing a user password etc. and access to native logs API
like syslog and other Windows logging.

And from those you will also get the “nice API” classes,
think UserManagement.createUser( login, password, other, options ),
that’s the next proto.

The pace of Redtamarin releases should increase, for 0.4.2 I kept the tools
like redbean unchanged, but the next versions of those tools will grow in
functionalities and you may have a new Redtamarin release 0.4.3 just to do that:
updates the tools.

On top of that you will get some “hello world” projects dedicated to show how
you automate and build stuff, for example: how to build an interactive shell,
how to build a daemon for Linux, how to build a daemon for macOS, etc.

And some published tutorials, that will focus on building simple tools like
how to build a TCP/UDP port scanner, how to build an HTTP server, etc.
which some more details on the why it is done this way with Redtamarin.

Not sure of the format yet, it could just be the classic blog post or even
published within a book or something.

That’s about the plan for this 2017 roadmap.


#2

and a bit later you see this kind of post

Programming languages that are actively developed on GitHub
Hacker News
Github Programming Languages

see, this illustrate a lot of things I said above :smile:

Redtamarin is not in this list and that’s totally fine


#3

Redtamarin is a server side plataform using AS3 as language created and sustained only by you ?


#4

Redtamarin is also a runtime, and yes it’s only me.


#5

It’s crazy!

Why you did it with very mature platforms:
ASP.NET/WebServices (C# or if you are a VB fan VB.NET) - Can mary with Flex easily with FluorineFx
Java - Didn’t use with Flex but I’m sure that it’s easy to integrate
PHP - Can mary with Flex easily with Amfphp

I already used PHP in past with Flex and it’s so easy.
I’m using C# with Flex and it’s so nice with LINQ and EntityFramework.

Really, I don’t get why you did it.


#6

You could say the same about anything really

why do Python or Ruby when PHP already exists?
why do HHVM when mod_php already exists?
etc.

So why do Redtamarin ?
because I can :smile:

And I also know there are some things that can be actually better than everything you mentioned above

First I see the ActionScript 3 language as “as good” if not better than C# or Java.

My point here is that deploying C# apps or Java apps on server(s) is a fucking heavy process.
And It’s kind of the same for Python, Ruby, Node.js, etc.

PHP is kind of easy by default with mod_php and Apache, but then you need fpm, HHVM, etc. and there it can get very complicated real fast.

Also from http://www.mono-project.com/archived/cgi/

ASP.NET (and Mono) has a relatively long startup time and requires a relatively large amount of initial memory that makes it unsuitable to be used as a CGI application in the traditional way because CGI requires the web server to create a new application process for each request.

You see that, well… with AVM2 we don’t have that.

AVM2 has been engineered for fast startup, in fact it is so fast that it can even be used for shell scripts (I know that because as3shebang, in a fraction of ms it can not only start a full blown VM but also on the fly interpret AS3 scripts).

And that’s the whole irony, when Adobe made AVM2 favour fast starts instead of the slow start of JVM and other ILR (.NET), they were doing that mainly for those 100MB+ SWF where the ABC code was loaded first and the assets could be streamlined later.

But that very same thing (the “fast start”) is exactly what make AVM2 more suitable to do CGI and other shell scripts, compared to Java or .NET/C#.

Now for those other things

  • ASP.NET/WebServices can mary with Flex easily with FluorineFx

  • Java can use BlazeDS

    BlazeDS is the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Adobe® Flex® and Adobe AIR™ applications for more responsive rich Internet application (RIA) experiences.

  • PHP can mary with Flex easily with Amfphp

  • and many other AMF backend libraries for Python, Ruby, etc.

Hey what about having an AMF backend in ActionScript 3 ?
with full support of ByteArray and full support of AMF serialisation / deserialisation ?

AVM2+AS3 can do that, I know I already did, I have a full functioning AMF server based on Redtamarin.
The only difference is that you program your backend in ActionScript 3, but that’s the difference I want.

But now let me ask you that, once you have Java program, is it easy to deploy and install ?
or same for a C# program, or a PHP program ?
What if you want to distribute a binary and not the sources ?
What is you want those binaries to work with the same API under Windows, macOS and Linux?

With Java or .NET (wether it is Microsoft or Mono) you will have to install at least a runtime,
with PHP you will have solution like PHP2exe but that’s only Windows, etc.

Lots of those things are easier and faster to do with Redtamarin.
And that’s only the tip of the iceberg.

Ok, some specifics.
When you use Amfphp, you still have to write the equivalent of your AS3 value objects in PHP,
you can autogenerate them to some extend but when things get complex you have to write
about the same thing both in AS3 and PHP.

With Redtamarin, the very same AS3 class is used both client and server side,
wether it implement 1 or many interfaces, wether it has specific methods, etc.
it is the same class.

Wether I serialize this class to AMF, I can send it trough the classic AMF with RTMP over HTTP, and RTMFP, and also custom socket protocols of my own because my backend understand natively AMF.

LINQ and EntityFramework are .NET things, I don’t need those.

I don’t use SQL DB I use NoSQL DB, and for that I use CouchDB,
if I need to serialize an AMF object to CouchDB, from AMF I deserialize to native AS3 then I can serialize with JSON for CouchDB and vise versa.

But I can do many other stuff: I can have in-memory data with a ByteArray running within a daemon,
I can directly save the AMF to disk if I want to and reload it later and have it available as a native object instantly,
I can have atexit hooks in case of daemon crash that write the whole in-memory ByteArray to disk which get automatically reloaded when the daemon restart.

I can have in-memory ByteArrays running as daemons on many servers synchronised over socket with atomic commits, the daemons can spawn different workers: one to write to logs, other to sync data with the current server instance, other to send/receive data over socket, etc.

Things like Entity Framework for .NET or other frameworks like Spring or Hibernate for Java, or any ORM in fact,
there are a common evil to be able to work with “objects” while you are still saving data records as “row” with SQL.

Look at something like System Properties Comparison Memcached vs. Microsoft SQL Server vs. Redis

with an in-memory ByteArray that run inside a daemon you get

  • a key-value store
  • schema-free
  • that support types
  • with a proprietary protocol which is AMF3
  • shareable between workers
  • also stuff like atomicCompareAndSwapIntAt()
    and atomicCompareAndSwapLength()

it is basic but let’s say you use that instead of MySQL to store users sessions id,
and any amount of properties (key-value) per unique id

even if you are lazy and do

  • use the unique session id as an Object or Dictionary key
  • basic readObject() / writeObject() to serialize / deserialize a UserSession type into each key
  • it is freaking fast

if you want more performance, you do about the same but

  • use IExternalizable and write/read only integers
  • use shareable ByteArray to atomicCompareAndSwapIntAt()
    a property value
  • use shareable ByteArray to atomicCompareAndSwapLength()
    add/remove/update properties length
  • each index is its own ByteArray
  • it is super duper freaking fast

I’m not sure how long it takes on your side to get such object with properties with LINQ/EF etc.
but here with AS3/AMF/ByteArray I can access any user sessions id and their properties in O(1) and in few milliseconds.

When I’m talking about thinking out of the box it’s about things like that and that’s why I do it with AVM2 and AS3.


#7

OK, I see some good and bad points on your choice.
It’s your choice any way.

I already worked with PHP+Flex+MySQL and I have created my own mini-framework on top of PHP with no need for VO on server-side.
Also I don’t need to create services for every entity. Basically I have very generic services and when I need something very specific I can extend and create a service.
For deploying was very easy because almost every host have lost cost options with PHP+MySQL enverinment. It’s just copy-past from FTP.

For the last 3 years, I’m working with C#+Flex+SQL Server on Windows environment (I don’t need Linux here because it’s SQL Server anyway - however there is now SQL Server for Linux but that’s another topic and it’s a recent option to evaluate some day).
Almost every Windows host haver already .NET 2.0 to 4.X installed + SQL Server Express (there is also options to rent SQL Server Web if you need).
It’s almost as easy as Linux host. Just copy-past with FTP (after you create the virtual directory).

You have a point about the slow startup on .NET however there is several “hacks” to solve this issue putting the service on warm and it works and if you have access to the server you can nativelly do this without workarounds (supported for years since .NET 4.0).

On my case I use the same backend for a Flex Desktop App (using AMF) and a HTML5 frontend using .NET WebApi and reusing the same logic for the Flex Desktop App and HTML5 Web App.


#8

There always gonna be different languages and eocsystems and choices etc.

my point was more about saying using AVM2 + ActionScript 3 on the whole production line
is not that crazy of a choice :wink:

When you focus on what you have native and integral to your runtime, for example: AMF,
and “ignore” what you don’t have from other environments, you can do a lot.

See how PowerShell under Windows can exchange “data blob” between command line tools?
With Redtamarin + AMF you can do about the same by piping AMF byteArrays directly to stdin and stdout.

For .NET being already pre-installed on Windows, my point was really about dependencies: what happen if it’s not pre-installed and it’s not Windows?
A Redtamarin projector (that is your program bytecode merged with the redshell runtime exe) is self-sufficient and have zero dependencies and can fit in about 5MB more or less.

.NET, Java and even Node.js have all the same problems to me: huge dependencies;
When a dev decide to build his own command-line tool written with JavaScript and depending on node.js/npm I don’t find that particularly efficient, on the doc you will see “oh just install node.js/npm then install my tool” but just that can be a freaking nightmare for most.

With Redtamarin I not only solve the problem of writing command-line tools fast, but because of the nature of the runtime itself it allows easy deployment to an exe “as if” it had been written in C, and with a bit more work with glue for node.js API, ChakraCore API etc. the same dev could still use JavaScript and publish an exe without the whole dependencies bullshit of node.js/npm etc.

I did the test with tsc (TypeScript command-line tool) it works :slight_smile: .

And that’s my other point, even if your focus is mainly on the backend development, my bet is that you still need command-line tools and other utilities to test locally because local testing of backend sucks.

Wether it is installing the same server stack on your local machine, or using a VM or using something like Docker, etc. all that sucks big time.

I’m still tackling this problem with Redtamarin but the goal is simple: write your code in an IDE like Flash Builder, have a local server that works like the remote server, test/debug with it locally, when done publish your bytecode to the server, and done.

And I can understand that using VS and having a local IIS instance to test etc. can work for you, well… under Windows, but me I want the same thing but simpler and easier and that works everywhere, not just Windows.


#9

I agree with zwetan on having an all in 1 package for the backend is a nice idea. I as well do C#+SQL back-end and Flex/Air front-end, but I need to distribute the back to my customers and the front-end to their customers.

My customers are lite on technical expertise and their customers are non-existent on technical. It’s a pain to make sure my customer has all the pre-requisites before install or upgrade, where as the front is always just load and go. If we were to do it over again I would seriously look at something like Redtamarin + SqlLite for the smaller customers because of the all in 1 packaging.


#10

zwetan, I don’t know anything about Redtamarin. I am working on a new project that would be a Linux daemon or Windows service that is configured with an Air app. The backend would need to load and run arbitrary logic (swf file?) and read/write to SQL and USB ports. Could Redtamarin handle something like this?


#11

For daemons, only Linux and macOS are supported so far,
I need to put a bit more work to have background services working for Windows.

To configure it with an AIR app, sure you could for example communicate
with the daemon over sockets and use AMF, text, XML, JSON, etc.

For the backend to load SWF file, it’s not there because it would be almost like making
a “Flash player” and it’s not really the goal of Redtamarin, here the things missing:

  • full support of the Flash/AIR API
    planed to support some but not all of the API in AVMGlue
    this can take a while
  • Redtamarin runtime can load SWF files but support only
    2 tags of the SWF format, supporting all the tags is quite a lot of work,
    even worst associating the parsing of the tags to some native AS3 classes
    is even more complicated etc.
    supporting a bit more tags may happen but not planed yet
    supporting all the SWF tags is very unlikely to happen
  • to really support SWF we would also need to implement things like Events
    and a “runtime main loop”, this is planed but will land in v0.5.0
    which is at least 1 year away.
  • read/write to SQL is not supported in Redtamarin yet
    this would require a “driver” and/or lib to connect to SQL
    I had planed to support SQLite, maybe mySQL/MariaDB, etc.
    but it’s not there yet, a “hairy” workaround would be to use
    the MySQL HTTP Plugin but clearly marked as “NOT FIT FOR PRODUCTION”.
  • reading/writing to USB ports is not supported nor planed
    but if such updates (which probably require to do it native) is not too big
    I could look into it and add it to the native API at some time later

Nope, sorry.

I have that request a lot but Redtamarin is unlikely to support ever a
“drop the SWF I build some other places there and run it server side”.

It does run SWF files, but you have to plan what goes into that SWF file
in term of API and features in order for it to be compatible to work with Redtamarin,
see for example as3-universal-analytics.

Things like loading a SWF that then build MovieClips, apply filters, export to Bitmap etc.
unless there are magically a massive amount of sponsors and contributors
it will almost certainly never happen, because Redtamarin focus on the GUI
and everything display list, stage3D, etc. even if it is implemented at the API level
with probably a lot of NO-OP will not be implemented at the rendering level.

Now if inside your SWF it is mainly AS3 logic, parsing files, updating data, etc.
or simply put it does not depends heavily on the Flash/AIR API to do work
like for example “ouh I would like my multiplayer game loop AI logic to be done server-side”
yes this is intended to be supported.

But in most cases it is unlikely that something that was build for FLash/AIR could jsut be dropped into Redtamarin and expect to work “as is”, nope guys, you gonna have to put some work into it too, the runtime can not not do it all for you :slight_smile: .

It will get better with time with more API, more libraries etc.


#12

So far it went like that for me with one of my app

  • oh let’s do a very basic thing a chat server
  • great it will fit Redtamarin API and stuff
  • tons of good stuff, like being able to define “socket protocols” based on AMF
    use registerClassAlias() client and server side and share those AS3 classes
  • then ouh I need to do daemons, so added that to 0.4.2
  • oh this is missing too, so added it to 0.4.2
  • oh I had totally underestimated that
  • etc.

I can do a lot with Redtamarin but so far I try to build with it and then add the stuff needed “in production”, it could be supporting daemons/background services, or simply having a way to package easily so you can then deploy easily, etc.

I can do and add a lot into Redtamarin, the changelog for 0.4.2 is about 400+ lines,
I organised my time/work/etc. so I’m in a somewhat regular schedule working on it
(with the added bonus that the work setup kind of sponsor the work on it), but still …

I’m still one guy :slight_smile:

What you are mentioning for the customers etc. I approach the things like that too,
sometimes it fit and some other times it’s just not possible.

For the record, SQLite support and API is planed for Redtamarin but not there yet,
the idea would be to integrate the sqlite C library natively, have access to C functions,
and then implement the AIR SQLite API on top of all that.


#13

This might still work for me. I have no need for anything visual or flash based, all pure AS3 logic and number crunching and nothing has been built yet. I am mostly concerned single file deployment and Linux / windows compatibility. Thanks a lot zwetan.


#14

It is the same reason the JavaScript developers like Node.js. They can use the language they already know and are familiar with on the server. They can also use all the tools that support JavaScript. Now the same goes for AS3. All AS3 developers can use a language and tools they are familiar with. And there is also the performance reasons.

Maybe one day in the distance future it will be possible to create a full client and server application in one MXML file. The client and server code could be side by side. For example, in your Flex application you could have a script tag that is of your server code:

<fx:Script runtAt="Server">
      var database:MySQL = new MySQL();
      
      public function postResults(post:Form):void {
             database.insert(form);
             // ...etc
             return new Results("OK");
      }
</fx:Script>

Then when you compile your app it will generate two files, the client swf and server swf. I don’t know if Redtarmarin will support this workflow but if not even a simple app or ant script can parse an XML file, grab the server tags and then pass that AS3 code to a compiler to generate the server swf. Or if the file is text it would copy the AS3 to an MyApplication.as file. Or you have two projects and one is the AS3 for server side. I don’t know how it works yet.


#15

It can go further than that.
Redtamarin cover the CLI, not only for server-side, but everything that can be done on the CLI.

It has a lot to do with tooling as “how can you build your own tool fast as a developer”

ActionScript 3.0 is great in that sens that it is hybrid, you can use it as dirty as you want:

  • not compiled
  • no types, no classes, not packages
  • just straight into the code to get the job done as fast as possible

and if you need more then, you can use it as structured/organised as you want:

  • put things into a class
  • use some types
  • isolate into a package
  • compile it into a library

People in general underestimate a lot the command-line, that “tooling” part

wether a dev want to automate something, repeat a common thing he/she does a lot,
build his/her own tool, share that tool with others, etc.

it should be easy to write and one of the goal of Redtamarin is to exactly do that.

It could happen like that, but right now it’s not.

Now the approach is more like building a SWF.

You gather the AS3 libraries you need, you write your code, etc.
to build an application and wrap it all, contain it, in 1 single file: a SWF.

You can run that “client app” either as an embedded SWF in an HTML page,
a SWF wrapped into an executable/runtime like Adobe AIR.

For the server-side it is about the same: you build an application that in the end
will end up into 1 single binary file.

it can be an ABC file (by default), but it could as well be a SWF file (containing your main program ABC and few others external libraries ABC).

But the principle is the same: you have one container that has everything your application need to run.

When it run server-side, it’s just an HTTP server that present input to your app, and your app generates output for that server.

I’m not a big fan of 1 file that would contain both client and server code, but it could be done.


Example event system in AS3
#16

Hey, great work!
Nice to read some serious stuff about AS3 still, in 17 :slight_smile: I’m rather graphic/audio guy but I can see great potential here. I wonder If you anticipate to get any help from other developers? I’m currently mainly focusing on developing GUI library on flash graphic api, or praraller to it would be better said - I designed it so that rendering engine could be replaceable in future as easy as possible, no Sprite extensions etc… but Occasionally I’m doing some other stuff as there is always something useful to write… :slight_smile:


**admin edit:** moved rest of the questions to another topic see: [Some questions about Redtamarin](https://discuss.as3lang.org/t/some-questions-about-redtamarin/609)

#17

thanks :slight_smile:

well … contribution on redtamarin is a bit complicated because it can involves compiling C/C++ cross-platform, but have a look at How To Contribute