Aurigma has more than 7 years experience on the market of Web upload solutions. You can find our products on many web sites all over the Internet. Today I would like to introduce our new product based on Flash technology.

Currently there are 4 widespread technologies allowing uploading files from client machines to web sites: ActiveX, Java, Flash, and Silverlight. Each of these technologies has its own pros and cons:

• ActiveX allows using native C/C++ code to get best performance and access to low-level OS functionality. However, ActiveX controls are supported in IE only. Of course, it still holds more than 50% of the browsers market but it is obviously not sufficient for publically available web site. Also there are security aspects with ActiveX components – some companies do not allow ActiveX controls in browsers on client machines by network security policies.
• Java - powerful, mature and widespread cross-platform technology. Google says that more that 80% of Internet-enabled computers have Java installed. Java Uploader - it is a solution working on Windows, Mac, and sometimes - on *nix, supported by the major browsers: Opera (win/mac), Firefox (win/mac/linux), Chrome (win), IE (win). Which contras does it have? It is slower than ActiveX. Most browsers restrict memory available for applets to 60-90Mb, so it is rather tricky to process large amounts of data. There are several Java implementations provided by different vendors, each potentially may have its own features and restrictions.
• Flash - absolute winner in popularity, at least on Windows/Mac. It is installed on more than 90% of Internet-enabled computers (thanks to YouTube) and very-very popular. Flash has reputation of "safe" client-side technology. But, "safe" always means "restricted" - and you can notice that Image Uploader Flash has fewer features in comparison to its “big brothers” – Java and ActiveX.
• Silverlight – in terms of upload functionality this Microsoft technology is very similar to Adobe Flash.

Historically Aurigma utilizes two of these technologies in its flagship product Image Uploader Dual: ActiveX and Java. This trick allows covering major currently used browsers. Sometime ago we started to think about third component for a perfect upload solution - Flash Image Uploader. The main strength of which is that it works almost on every client computer. It may be used as fallback solution in cases when Image Uploader Dual cannot be started on client machine. Flash still will be much better solution, than silly "browse" button. This product will meet requirement of our clients who do not need “heavy” functionality, like processing large images client-side or sophisticated user interface. Or it may be an additional option for sites, which want to provide their visitors with really rich choice.

During years of work on the market of upload solutions we accumulated experience in the field of file and image transfer. While working on new our product we used it to create flexible and simple solution. You should not implement any HTML-controls to make Image Uploader Flash work on your site. You should not write additional JavaScript code to embed Adobe Flash Player and so on. We have already done it for you. New generation of client scripts, ASP.NET and PHP controls allow you to save your time. The product will come with samples and we encourage you to use them as starting point for your code. Our goal is to provide you with solution that just works. And we hope that you will like it.

Here is how Image Uploader Flash looks:

If you would like to see Image Uploader Flash in action, it is available on our site: http://demo.aurigma.com/imageuploaderflash.

Recently we have decided to widen our experience (and maybe products line) and to investigate new Flash/Flex platform. The task was to create file-upload solution with some client-side image processing. This post contains a summary of our experiments. However, I'm a full newbie in Flash/Flex, so feel free to add your notes and comments.

The beginning was great - I have just opened FlexBuilder and found many cool things. Stable and fast visual forms designer, easy-to-learn syntax, all major OOP concepts and even compile-time type checks. Oh, and of course - shaders! Really amazing stuff. However, after few days my impressions were not so bright. Why? Here the whole list of reasons.

Security restrictions

It is really a problem number one. As I was interested in upload functionality, I started with URLLoader class. It cannot post anything to server if this action is not initiated by user directly. Very reasonable. So, each time when you call URLLoader.load() you should have something like button click handler higher in stack. It prevents malicious apps from stealing user data. But...

There is another thing about Flash/Flex which you should know. It is event-driven platform with many asynchronous calls. E.g. if you want to load file - you should call FileReference.load() and wait for "complete" event fired by this object. If you want to load SWF movie or JPEG image - you should create Loader object, ask it to start processing and just wait for the event. Very simple! If you are not going to upload an image you have, to go to fullscreen or do anything else from the list of restricted actions. But if you are - you are in a big trouble. By the reason of the fact that "complete" event fired from another thread - there is no UIA (user-initiated-action) handler in stack and, hence, you have no permission.

Adobe docs says - "you should show message and ask user again". You have to ask, even if a user just clicked "Do this" button just because you have asynchronous call in the middle of your operation. Really annoying. Actually, I don't understand why a bad guy cannot show message and ask user some innocent question? User will give him a permit (why not, if question is innocent?) - and he will do his dirty business...

And there is also another bug with URLLoader - it doesn't fire progress event while uploading data from binary buffer. It is a known issue and I even voted for it. I would recommend you to do the same if you experience a similar problem.

So, URLLoader was evidently not the best choice. Next thing I tried to use was Socket. Yeap, it is not so easy to use, however, from the other hand it gives much more flexibility. Nevertheless, a few hours later it was evident that Socket is not the option at all because even if you are going to make uploads to the same domain where you host your SWF file you should have special policy server installed on the server. You cannot obtain permission policy from your HTTP server, no, only via special policy server...

Threads & Asynchronous calls

As I mentioned before - Flash/Flex is an event-driven asynchronous platform. But it doesn't support multithreading. Sounds strange, yeap? As far as I understand from blogs and forums - all ActionScript code is executed in a single thread. And asynchronous calls are just enqueued in some internal dispatcher. What does that mean? That it is simple to develop, it is hard to make a hardly-debuggable synchronization error. And this means, that you cannot run anything in background. There are workarounds which emulate "background processing", but they were not applicable in my case. Oh, I forgot to mention that shaders engine works in another thread, so if your task can be expressed in shaders programming language - you will be able to do it asynchronously and very-very fast. ;) Unfortunately, it isn't my case as well.

Summary

What do we have at the end? A very strange feeling. Get me right, I like Flash/Flex - it provides a bunch of great features, it allows to develop really fast, it works in a stable way... But sometimes it stalemates you, and you cannot do anything. Users will have nothing to do than bear user interface freezing or answer useless questions shown because of security restrictions in Flash.

It would be great to have the following things in the future:

• Signed SWFs or any other mechanism to use instead of UIA concept. Or some mechanism which will allow passing UIA-permission via event chains.
• Multithreading or at least something like yield() method.
• Ability to work via sockets. At least with native domain. Without any "special server on XXX port", because it is not usable in real world with hosting providers, firewalls, and proxies.