The way the feature should work is that the Alfresco Share application takes the PDF a user uploads into the document library, converts it to an SWF using swftools (one frame of the SWF per each page of the PDF), and then uses the YUI framework to “play” the resulting SWF.

The problem is that for me, depending on the version of Flash installed, the preview SWF cannot be displayed. (Short version: Flash 9.0.45-47 works fine, later Flash versions just result in a spinning cursor which never resolves. The problem is Flash 9.0.45 breaks file upload, which works in later Flash versions).

Good Flash

Bad Flash

Just finding this out required a lengthy exercise including full uninstalls of Flash (using Flash uninstaller for Mac OS X, which takes forever since it is a PowerPC binary running on an Intel machine) along with installs of various versions of Flash from the 9.x archive.

It was in this context that I was so happy to see the dialogue Dion Almaer and Brad Neuberg posted at Ajaxian today: How Flash Can Join The Open Web.

The conversation began on Dion’s techno.blog(“Dion”) with The Flash Platform: How Adobe could join the Open Web to take on . . . in which he argues:

With Silverlight making a huge charge I worry about a world where you have “Best viewed in Silverlight and IE” (which in fact is “only viewed in…”) and people often ask: “But isn’t Flash just as bad?”

Adobe has an opportunity here. They can move to the right and Flash could become strongly in the Open Web camp. Then we would all be stronger as we come up against Silverlight :)

Indeed, Dion’s image, which he used to show the developer perception of Flash and Silverlight together in contrast to the Open Web isn’t that much different than this image I’ve used in previous blog posts here:

Brad responded over at coding in paradise with How Flash Can Integrate With The Open Web, in which he argues that:

Adobe (and Macromedia before it) has always been good about evolving Flash forward, including making ActionScript more like JavaScript, embracing markup language development, open sourcing Flex, and more. I’d like to see Flash continue to evolve into being a core part of the Open Web. This would be good for Flash and good for the Open Web.

As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a ‘black box’ on the screen.

He goes on to list a number of ways that “Flash should start working like the web itself”:

• Directly push Flex and ActionScript to the browser and Embrace View Source
• Integrate with Bookmarking and History
• Don’t Be Afraid of the Browser
• Hyperlinks Are Your Friend
• Embrace REST and Readable Remoting Protocols
• Embrace SVG
• Integrate With HTML and CSS
• Make Friends With HTML 5 Video
• Support Both Documents and Applications
• Start Working with the W3C and IETF (and/or the Open Web Foundation)

Now, of course it’s not fair to blame Adobe for my troubleshooting woes of the last week – more likely something about the SWFs produced by SWFTools or the way Alfresco Share is trying to pass them through the YUI Components is to blame, and it’s just that some versions of the Flash player are more forgiving than others.

But how much easier would it be to debug such an application if the Flash plugin didn’t create such a “black box” in the middle of my web application? What if I could dive into the running Flash application the way I can dive into the document object model in firebug, and determine the states of objects and content of variables?

Like Brad and Dion, I like what Flash is capable of, but so much more great innovation could be built with Flash if it were more integrated with the rest of the evolving web stack – whether that means open sourcing all of Flash or just finding ways t work with browser makers (commercial and open source) to make the content and interactivity in SWFs more accessible to the end user.

As Mike points out, the fact that the Tamarin is an open source project, and that various people in the community have over time deciphered the SWF file format, does not make Flash anything other than a proprietary product.

In many of the presentations I give about rich Internet applications, I use a slide which looks something like this:

It’s intended to communicate two key concepts:

1. There are a huge number of mature, professional open source toolkits and frameworks for building RIAs.
2. There is strong pressure on proprietary, closed, commercial toolkits and frameworks in this space to open up, at least in terms of source code visibility and modifiability, if not in terms of redistribution.

I suppose one could argue about the relative placement of Silverlight (which coincidentally this morning is throwing classic “Server Error in ‘/’ Application.” errors), since there is will be an open source implementation of it (moonlight). Adobe Integrated Runtime (AIR) similarly is a very proprietary package although it leverages webkit and Adobe cooperates with / contributes to the webkit community. The Flex SDK is free (as in beer, not as in freedom), though my impression is that teams which expect to do serious Flex development work end up using the proprietary toolset and other closed-source pieces (AMF) in addition to what is in the open SDK.

Does it matter? Do you care if the framework on which you build RIAs is fully open, partially open, or not at all open?

As I argued in my discussion of Mozilla Prism versus AIR, I think it matters quite a bit in certain scenarios, perhaps less in others.

At a minimum, before you invest significant development time (and therefore dollars) in building on a given framework, you ought to have a clear understanding of what parts of it are open and what parts are not.

As the following image (from the Mozilla Labs Prism page) illustrates, the idea is that Prism splits apart the light coming from the cloud into separate apps. (I know, light doesn’t really come from clouds, but you get the point):

In essence, what Prism does is simply to create a single-url loading instance of firefox without all the browser chrome – so that the application gets an icon of its own, has an entry in the Start menu, is accessible via alt-tab application switching, and the like.

Its an interesting direction for WebRunner, and a good step forward for some specific use cases along the desktop application / web application continuum. Take an app which has offline sync via GoogleGears, run it inside Prism, and you’ve got a desktop application which syncs to the cloud but can also be accessed from other non-prism browsers when you are away from your machine.

(For more info on Prism, see Read/Write Web, Geeks are Sexy, Alex Faaborg’s discussion of its UI, feature suggestions on Prism Brainstorming, Mark Finkle’s discussion of changes from the existing WebRunner, and the forums at Mozilla Labs).

In the process of explaining what Mozilla Labs is up to, the (anonymous?) Mozilla Labs blog entry author said:

Unlike Adobe AIR and Microsoft Silverlight, we’re not building a proprietary platform to replace the web. We think the web is a powerful and open platform for this sort of innovation, so our goal is to identify and facilitate the development of enhancements that bring the advantages of desktop apps to the web platform.

This got the attention of Adobe’s Mike Chambers, who first posted in the comments on the Mozilla announcement, taking issue with the idea that Prism is fundamentally different from AIR. After all, he noted, AIR also runs applications developed on web standards and runs them in a desktop container with some additional desktop-like features:

So, is the main difference between something like Prism and Adobe AIR, that Adobe AIR is being primarily developed by a company (Adobe), and that Prism is being developed by Mozilla?

Later, he expanded on this issue in a blog post: “Mozilla Prism and the Disingenuous Web,” repeating the notion that AIR and Prism seem quite similar in goal and usage, and complaining:

Come on Mozilla, the web development community deserves better than that. Adobe has been an active supporter of the web development community, of open source, of web standards and of Mozilla (donating the ActionScript virtual machine from the Flash Player (Tamarin)). Adobe AIR leverages a number of open source technologies (including Tamarin, SQLite and WebKit) and we actively participate in both of those development communities, and we have been open with our development process for some time.

So what does differentiate Prism from AIR? (See also “AIR, and a Prism” at Technological Musings for another comparison)

Mozilla Prism, for now, is Windows only; Adobe AIR, for now, is Windows and Mac OS only. Both have promised Linux support in the near future.

As several readers pointed out in comments threads on both Mike Chambers post and the one at Mozilla labs, the Mozilla foundation has a better track record at porting applications to Linux than Adobe does. (Flash Player 9 notwithstanding).

(Note that Linux and MacOS X installers are already listed in the Mozilla Labs Wiki – I’m trying one out in Linux now, and it seems to work just fine).

Adobe AIR is based on WebKit (also used in Safari, originally from the Konqueror browser in KDE) for rendering HTML; Mozilla Prism is based on Firefox. AIR can handle flash content, pdf content, or Ajax (HTML/JavaScript) content; Mozilla Prism can as well, though it relies on the same plugins the Firefox browser does to support these other content types.

One significant difference is that Adobe AIR applications are created by developers, who do some “extra work” to create and package their application as an AIR application, whereas Mozilla Prism applications are created by end users, who take an existing web application and tell Prism to run it.

Finally, and perhaps most importantly, while AIR “leverages a number of open source technologies (including Tamarin, SQLite and WebKit) and [Adobe] actively participate in both of those development communities, and [Adobe] have been open with our development process for some time” (quotes from Mike Chambers’ blog post), Mozilla Prism is itself an Open Source project (Mozilla Public License).

What this means it that if the development community is unhappy with the directions in which Prism is going, they can fork, and take the existing code base in different directions.

Or, working in collaboration with the existing project, they can extend that code base, taking it to other platforms or contexts.

In other words, I’d say the difference isn’t, to answer Mike Chamber’s question, that one is developed by a company (Adobe) while the other is developed by a foundation (Mozilla), but that one consumes and participates in open source (Adobe AIR), while the other is itself fully open source (Mozilla Prism).

That’s not to say Adobe has not been a good open source citizen or contributed appropriately to WebKit, SQLite, and others – I believe they have contributed substantially to a number of projects. It’s just that an implementation which is fully open is preferable, for many folks, to one which is mostly open except for where it isn’t.

I’m surprised that is still so hard to understand.