Free Flex, Get Your Hot Fresh FREE Flex!

Ok, let's go through this again ...

In Flex 1.x world, Flex is primarily a server. You write MXML and AS code, post it on the server, it gets compiled to a SWF, which gets served back to the client. What Macromedia (and now Adobe) sells you is the server (the software which is deployed on a J2EE server). In other words, you need the server to publish Flex applications. And yes, I know that this is a bit of an over-simplification, and yes, I know that you can actually deploy serverless apps in Flex 1.x - I'm talking about the typical deployment and the standard licensing.

In Flex 2 this all changes. A server is no longer needed to actually serve Flex requests. You may in fact want a server (Flex Data Services), but it is not actually needed. In Flex 2 you can write your code (MXML and AS) and then compile it, generating a complete SWF (in much the same way as Flash generates standalone SWFs from FLA files) which can be deployed on your HTTP server just like any other assets (HTML files, GIFs, CSS files, etc.). And the generated and deployed SWF can talk back to the server via HTTP call, AMF (Flash Remoting), and SOAP (Web Services) - and no, once again, this can be accomplished without needing Flex installed on the server.

So, how do you create and compile this SWF? There are two ways to do this:

1) Use Flex Builder, an Eclipse based IDE which (as we have repeatedly publicly committed) will have a street price of under $1000 for a developer license.

2) Use any editor to write your MXML and AS, and then use the FREE Flex 2 SDK (a command line compiler and accompanying framework) to compile your code into a SWF.

Simple as that. Either way you'll have a SWF which can be deployed on any server, even a server not running Flex server software.

So far so good? OK, so on to the server.

There IS a server in Flex 2, it is called Flex Data Services (or FDS for short), and it gets installed and deployed on top of a J2EE server. You can serve MXML and AS code via it (in which case the server will compile the app, just like Flex 1.x does), but that is not the really compelling reason to use FDS. The really compelling reasons to use FDS are the additional functionality, including:

* Server-to-client push: the ability to push data to the SWF running in the Flash player without needing to use timers and polling. For example, you could push real time pricing data in an auction application. Or you could push real data numbers to update charts dynamically. Or you could push chat window text in a peer-to-peer (via the server) application. Or ... you get the idea.

* Data synchronization: the ability to safely handle concurrent access to back-end data, tracking data changes, and safely handle conflict resolution. No more last-edit-overwrites-any-prior-edit, you can write code that ties in to back end data and talks to the Flash client, providing real end-to-end data synchronization.

There's more, but you get the point. Using FDS you can essentially keep an open pipe between server and Flash client, giving you far greater control over your applications than previously possible.

Final pricing for FDS has not been announced, and some sort of tiered pricing is likely. But, we have publicly announced that an entry level version of FDS will be freely available.

So, in a nutshell, with Flex 2 Adobe will sell two things:

1) Flex Builder: Once you try it I think you'll decide that it is well worth the money. But if not, no problem, use the free Flex 2 SDK and an editor of your choice.

2) Flex Data Services: And an entry level version of FDS will be available free of charge.

Or put differently, you will be able to build Flex 2 for FREE! Yes, FREE! Free as in nada, zilch, zip, zero, nothing, naught ...

Want to get your hands on Flex 2? Visit Adobe Labs.

Ok, hopefully this is the last time I'll have to explain it, and if not, well, I'll just point to this blog entry. ;-)