The internet is a buzz with talk of the downfall of Flash. Flash, the only web platform with 99%+ penetration rate cross platform, and 90%+ penetration rate for their latest version only 3 months after release. The platform that powers the web's content, games, and more than 75% of all interactive online media. That's now able to power desktop and mobile applications, and with the imminent release of Flash 10.1 which will bring with it much more efficient and lower memory/ram usage, lighter on cpu so much that it's able to play HD Youtube videos on a mobile phone without a problem. Yes, Flash, the downfall of Flash.

There are two main arguments to these ridiculous claims. The first is the emergence of HTML 5. HTML 5 finally allows video and audio playback without any plugins, and canvas - a tag which allows for complex drawing, embedding fonts, etc. etc. Things Flash has been able to do for years, has a huge head start on, and does really well. The problem that nobody seems to get is that not only does Internet Explorer still have majority market share, by a lot depending on who you ask - and Microsoft will NEVER support standards because it's directly bad for business. Aside from that, and the fact that every browser that will support HTML 5(ie: everyone else), will also implement it differently from each other, with different aesthetics, features, code, BUGS, etc. But even more crucial aside from those things, the HTML 5 spec itself is not even complete yet. It's not even finished, and it's not finished in a deadlock between the web giants who not only can't decide or agree on which video and audio formats are the best performance wise, but also who owns the rights to implement those formats in their browser and who'll have to pay massive royalties if the true patent/copyright holders agree to allow it at all at any point down the road. No one wants to properly look this up for a variety of reasons and so HTML 5 - supposed to bring the web together and herald a new dawn of the internet can only work if EVERYONE does in fact come together and implement it in exactly the same way; disregarding that ubiquitous HTML 5 means EVERYONE loses something, some everything. It benefits none of the powers that be to come together on HTML 5, the web is a magazine with some interaction. HTML will never push out Flash for web applications.

The other main argument is the Apple iPad - just announced. Which like the iPhone doesn't support HTML 5. Apple uses the old "Flash is too resource intensive" argument to convince you that limiting you from the full web is a good thing. The 75%+ of online media and interactive content and games you don't have access to from an iPad or iPhone or iPod. This simply isn't true. It's false. Both iPhone 3Gs and iPad could happily run the current version of Flash or Adobe AIR just like your laptop/desktop. And it's also entirely up to the developer and how they program how resource intensive they make their flash app/widget/game/etc. The only reason, listen up, the ONLY reason Apple does not support Flash, is because the Flash platform already powers so many games and useful tools and full blown applications on the internet it threatens Apple's very business model of the Itunes Store, and App Store. Apple wants companies to develop all their apps again specifically for the iPlatform and invest in it. If you made a Flash app that ran on the iPhone it would also run on Android and every other smart phone. If you invest in the iPlatform your app will only run on the iPlatform. If Apple was a monopoly the FTC would be pushing them down for their anti-competitive vindictive behaviour.

Apple doesn't block Flash support in their mobile products because they want to push innovation in HTML 5. If HTML 5 was advanced enough, or popular enough to be worth creating the caliber of applications possible on Flash, Apple would immediately configure mobile Safari to block, impede, and hinder the advancement of standards just like Microsoft with IE. In a heart beat. Apple promotes HTML 5 because they know it'll be years before it's anywhere close to where Flash is today, if ever. Apple is actually one of the powers that be preventing the HTML 5 standards from being finalized. Apple wants you locked into their platform. Apple doesn't care about advancing the web, or a better user experience, they care about the big media companies investing in their platform when they bring their content online. Apple wants the iPad to replace your tv, radio, and other media consumption devices. They do not care about the open web.

Adobe on the other hand continues to open up the Flash platform and benefits from creating a ubiquitous platform across desktop and mobile. There are fully open source versions of their Streaming and Application servers, and free and open source ways to develop for their platform. Anyone can build a Flash application, for the browser, desktop, Windows, Mac, Linux, Safari, Internet Explorer, Chrome, Firefox, Opera, etc. etc. Build one application and deploy everywhere using an incredibly powerful, scalable, and mature toolset. If you decide to invest in the Apple iPlatform, you may or may not after months of development time and costs even get your application onto a device, regardless you have to pay Apple to be a developer and submit it in the first place or even get access to their development tools, and they can remove your software from their platform and devices at a moments whim. They can and do literally remove your application from people's phones after being downloaded used without warning to backup the data put into or created by your app. Anytime for any reason. AND if you're lucky enough to get your application through all these extra months of hurdles and costs and lost revenue you're only gaining access to one small subset of mobile devices. Apple, if anything, has become the evil mind controlling overlords from their 1984 ad. Too pathetic to be ironic.

It is absolutely ridiculous to think the HTML 5 is going anywhere anytime soon, let alone even coming close to eclipsing Flash in any way. Not from Apple, they don't want anything to compete with their platform for getting applications on their devices - Flash or otherwise(HTML, Java, Silverlight), and not from anywhere else because it's just not mature, complete, or will over the next 12-24 months be implemented uniformly or consistently across browsers or operating systems. Even in the event that somehow somehow all these competitors will come together in blissful glee to reduce their own profit margins and upset shareholders in the name of benefiting the user and happy popcorn rainbows, it will still only have the capabilities of Flash 8-ish, by then Flash 11 will be out and there won't be a need for web browsers anymore because every site will have a dedicated Adobe AIR application front end and you'll use an Adobe AIR application to browse through a market place of Adobe AIR apps. Yes we're moving towards the cloud, and yes the cloud and desktop are becoming indistinguishable, but moving into the browser is only a temporary measure for some companies before they build a desktop front end for their service.

The iPad, iPhone, and iPod are merely secondary devices - frills. Every person with an iMobile device also has a desktop or laptop for work and actually managing their digital life. The iPlatform's position on Flash is exactly insignificant, and every single person I've seen raving for HTML 5 and the downfall of flash depends heavily on flash and its phenomenal capabilities. They're all idiots.

I've been using a php script as a gateway to fetching certain content from a server, mainly mp3 files. There are a bunch of reasons for doing this, the main ones would be to be able to easily log which files are being accessed, when, and by who - and if you plan on creating widgets for your users to stream the content they upload to your site and they happen to put it on a heavily visited part of the web you can temporarily disable or limit that user's widget's access to content giving your other user's priority and preventing your server from crashing or being overworked.

So in the Flex/AIR app I've got a URLRequest that's used to load a Sound object. Instead of specifying the index.php it had been accessing http://domain.com?var1=blah&var2=blah. Usually this will redirect to the index.php sending it the post variables and letting it do it's thing and fetch the mp3. It works on Adobe AIR for Mac, it works in a browser on Mac/Windows. But in a URLRequest from Windows it doesn't work, confirmed for XP and 7. It doesn't just redirect to the /index.php file and drop the POST/GET variables, it actually just doesn't redirect anywhere, and you get an IOError. You'd think the redirect would be handled entirely by the server and transparent to the client, but it appears that for whatever reason, Adobe AIR on Windows just returns an IO Error.

Either way it's easy to fix, you just have to specify the index file in your URLRequest like so: http://domain.com/index.php?var1=blah&var2=blah.

You probably found this because you're trying to make a socket connection from Flex/Flash and getting the following error:

SecurityError: Error #2123: Security sandbox violation:

Adobe went through a number of phases making the rules for serving and checking Policy files stricter. There are different security sandboxes. If you publish your flex/flash application on domain.com, and the application attempts to load content from domain2.com, it will look for a Cross Domain Policy File at domain2.com/crossdomain.xml to get permission. It does this automatically, however you could specify the location of the Cross Domain Policy File in your flex application using the following method:

Security.loadPolicyFile("http://domain.com/remote_content/crossdomain.xml")

A Cross Domain Policy File only has authority to grant access to content below it in the folder hierarchy. So a policy file in /remote_content/ can't grant access to content in the root folder, and in addition a Policy File at the domain root can override any other policy file. It has maximal authority. Subdomains are considered separate domains - which as a side note most search engines see subdomains that way too.

Now that's Cross Domain Policy Files, In general Adobe Air applications operate in one of the local system sandboxes and has thus have access to content on any domain. This post is about Socket Policy Files. When you access regular web content you're generally connecting to your server on port 80 and being served content by Apache or whatever web server you happen to be running. When you do this you're using http protocols under the hood and never have to deal directly with that crazy stuff. If you want to make a raw socket connection to your server you will need to serve up a Socket Policy File on a specific port.

First I just want to stress the difference between a Cross Domain Policy File and a Socket Policy File. For some reason my dyslexia and the ton of misleading, vague, and now out of date and incorrect information I kept thinking they were the same thing. Second there is no way as far as I'm aware to serve a Socket Policy File with Apache.

The default port for flex/flash to search for a socket policy file on port 843. There are several places on the web that talk about being able to connect to higher port numbers without a Socket Policy File, well that doesn't seem to be the case anymore. Just assume that any raw socket connection from a flex/flash client requires a Socket Policy File.

You can serve the Socket Policy File from the port you're connecting to, but this is tricky considering the manner in which Flex/Flash goes about loading the Socket Policy File and rewriting the service to serve this up, especially if you're using server software built by someone else, means it's just better to keep the Socket Policy File Server as a separate always running entity on the system.

Now in the simplest implementations you need a process either written in python, perl, c++, php cli, or whatever. It needs to be listening on port 843. It has to wait for - very specifically - the following string<policy-file-request/> followed by a NULL byte. Upon receiving that it needs to serve up the policy file which needs to at least have allow-access-from domain set to *, and to-ports set to *. You should use the links at the end of this post to familiarize yourself with the differences between and all options you can specify in Policy Files. It's easiest to keep the Policy File as an actual file, instead of adding the text of the file to your custom server code. And that's it!, now you can go on with a better idea of what information out there is out of date or not.

Here are some important links to help you on your journey:

Adobe on setting up a Socket Policy File Server

Adobe on Policy File changes for flash 9 and 10

Adobe on the structure of Policy Files

An intro to Sockets

Working PHP Cli Socket Policy File Server