Why is there a library that builds classes and templates for C in an Actionscript site?

Because it has an Actionscript back-end that uses the same definitions to generate Actionscript code using the ‘C Preprocessor for Actionscript’ build chain.

Why ever on Earth would you want to THAT?

Maybe you just want to efficiently relay messages back & forth between Flash based clients for peer-to-peer games, or you have an MMO that you want to write and host on a dedicated Linux/Unix server. You can use somewhat less expensive dedicated hosting if you transfer more compact binary data and use a native server, rather than an interpreted one that at bests runs 1/10th as fast. A ‘custom’ server without 1001 back door options for scripting and ‘calling out’ to things is also more secure and easier for YOU to configure, while being a complete mystery to outsiders. Unlike those expensive closed-source behemoths like Adobe’s Flash servers, this is absolutely tiny and native (builds with your Linux/UNIX GNU C), leaving more server RAM and CPU bandwidth to handle users, rather than load up ‘services’ and back-doors that you never use and probably don’t even know about.

Though you can compile and run under Windows for debugging, a Windows server is NOT recommended for ‘live’ use, as WinSock sucks rotten eggs, and a Windows server will consume over half a 1GB host’s RAM just to boot. So, run several instances of your server under Linux, or use Windows and run one very slow and limited one. How hard a decision is that?

The server (and supporting code) as coded is SINGLE-THREADED. This is a ‘good thing’. For most models of where multiple users interact with each other, multi-threaded server code is a nightmare of locks and potential deadlocks. In this model, you get one select loop to do your dirty work in. If you have database or other file operations to consider, make a dedicated server to talk to your front-end server. This adds several important qualities. The database is in a separate process, not blocking the front-end server. If a bug crashes your front-end, the database won’t crash in the middle of an operation. The database can be shared by multiple front-ends. The connection to the database becomes a natural ‘queue’ for pending operations. As written, the socket code does few (or no) dynamic memory operations. This makes it inherently leak-resistant. It allocates all of what it needs at startup. This makes it trivial to decide how many servers ‘could’ run on a single machine. Just add up the memory footprint. It won’t get any bigger from there.

Also, the protocol (as defined, feel free to roll your own) supports raw serial data. So for a peer-to-peer messages, you can just dump AMF direcly into the packet to send to other Flash clients unadulterated. The server its self does not parse AMF. Too much trouble for too little return. The macros that build data use the flash.utils.ByteArray (IDataInput, IDataOutput) to build binary packets. This is a little extra work on the client to make a packet versus AMF, but a microscopic fraction of the work on the server to build and parse simple data types and strings instead of Flash’s internals.

http://squat.sourceforge.net/ http://flex2cpp.sourceforge.net/