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.

I’ve left a brief comment there, but wanted to expand on it here. This isn’t just a question of two different approaches to delivering Internet TV – it’s a fundamental difference of passive consumption versus active participation.

The fundamental difference between Joost and Miro is seen in these two quotes.

From the Joost FAQ, section on “Content Related Questions, ” the question is “Can I upload my own videos?“:

Not at the moment. Right now, we’re concentrating on high-quality TV content from well-known TV brands, so that we can provide entertainment to the widest possible audience. Future versions of Joost may allow you to upload your own material, but we have no immediate plans for this.

As opposed to, on the GetMiro site, the entire first-level tab called create, where one reads:

How do I get my Videos on Miro?

Miro converts any media RSS feed into a channel. Don’t worry if you’ve never heard of RSS — it’s an open distribution format that works with Miro, iTunes, and lots of other tools. Many blogs and video sharing services automatically generate an RSS feed. Once you have a feed that works in Miro (please test it first!), you can submit it to the Miro Guide.

With pointers to the Make Internet TV site, where you’ll find:

We have created a detailed set of guides for shooting, editing, publishing, and promoting internet video. We think it’s the best resource anywhere. If you are getting started with creating internet video or if you want to learn more about a specific topic, it’s the best place to start.

To me, this is the clear difference between Internet TV imagined as something brought to you by “well-known TV brands” (turning the internet into TV) versus Internet TV imagined as something inherently participatory (turning TV into the internet).

It shouldn’t be hard to tell which one runs on my machine(s).

Help spread the word:

Not sure how valuable the slides will be in the absence of my commentary on them, but here they are:

• Two Steps Forward, One Step Back (4.3MB, in ODP format for OpenOffice)
• Two Steps Forward, One Step Back (3.3MB, in PDF format)

Thanks to those who attended and feel free to contact me with any questions.

• Put users into plug-in hell.
• Create Web ghettos.
• Don’t provide accessibility.
• Make search a pain.

It’s a great beginning to a real debate about the place of technologies like Silverlight that many others have been fawning over.

He doesn’t mention one that I would add:

• Require users to accept closed, proprietary software. You can have a completely Free/Libre experience of using the web, until you hit Flash / Silverlight content, which cannot be accessed in a pure open stack, and may never be ported to Linux (Flash Player has finally been ported to Linux – no word on Silverlight).

My only nit to pick is that Apollo’s really not the target here so much as Flash itself is – Apollo’s really about extending web apps (which can be in Flash or Ajax) to the desktop. (The media loves an opportunity to put Adobe up against Microsoft – and painting Silverlight as going up against Flash would require acknowledging how long Flash has been in use).

That said, similar criticisms can be extended, since Apollo only deepens the distinction between those who have it and those who don’t, and extends the life of Flash as a web-delivery mechanism.

This week, add Microsoft’s Silverlight 1.1 and Dynamic Languages Runtime to the mix alongside Adobe’s Flex SDK.

Jeff Gould argues that open source has “jumped the shark,” and that:

the magical words “open source” have come to function as the software equivalent of carbon offsets. . . . some software vendors are cleverer than others, and have learned to buy indulgences for their sinful profit-craving ways by selectively building open source components into their stack. . . . Their own software remains every bit as proprietary as the Microsoft products they compete with.

Interestingly, his argument comes the same day that Microsoft announces the Dynamic Language Runtime at MIX 07.

The DLR will enable developers to code .NET applications in Python, Ruby and other dynamic languages to come (alongside JavaScript and VisualBasic) in addition to C# and VB.NET.

Adding in Silverlight 1.1, which will be a browser plug-in, this means that “developers building browser-based applications can now use their preferred language even for client-side code.”

How does this relate to Gould’s argument? The DLR, along with IronPython and IronRuby, will be made available under the Microsoft Permissive License, which they characterize as their “BSD-style” license. (For now code is available as part of IronPython ).

What isn’t clear is what this will mean in terms of deploying applications. Silverlight so far has only been described as “cross-platform” – and a specific version of cross-platform at that. As Gavin Clarke notes in his reporting from MIX 07:

. . . while Silverlight works in Safari, Firefox, and Mac versions 10.4.8 or higher on PowerPC and Intel in addition to Internet Explorer and Windows, support for Linux and Opera – to name just two other popular alternatives – is missing, with little prospect of support coming from Microsoft

In other words, you can develop with whatever dynamic languages you like, so long as you are working on a .NET platform. You can even deploy those dynamic language applications to browsers, so long as it is IE or Firefox on windows or Safari for Mac OS X, and using the Silverlight 1.1 plugin, which itself may or may not be open source.

(Elizabeth Montalbana at IDG says here that “Microsoft will release the source code to part of its Silverlight technology at MIX 07 this week,” but the Silverlight site merely says “Microsoft will make the Silverlight browser plug-in freely available for all supported platforms.” It looks to me like some of the DLR will be under the Microsoft Permissive License, but not the Silverlight plug-in itself).

This resembles / echoes Adobe’s recent move to open source parts of the Flex SDK, and portions of the ActionScript interpreter used in the Flash plug-in, but without opening the key portions of Flex (Flex Data Services, for example) and without opening the Flash player itself. (As well as not open sourcing Apollo, though they have promised Linux support at some future date).

While I think it will be interesting for .NET based developers who want the ability to flex their Ruby or Python skills on the platform on which they arleady develop, I don’t see any vast migration of open source developers into the Redmond camp, any more than I see Adobe’s gestures in the direction of open source moving those accustomed to open source ajax frameworks and libraries.

In fact, perhaps this becomes a way to expose even more .NET developers to joys of Ruby on Rails, Slingshot and Django.

Related posts:

• Talking Ruby and Dynamic Language Support with John Lam (Video, at Port25)
• Python, Java, Ruby, Oh My! Silverlight Alpha 1.1 ships with Dynamic Language Support (video, at Port 25)
• Mix ’07′s Sleeper Announcement: Cross-platform CLR
• Silverlight Glow Dimmed by Cross Platform Concerns
• Mix 07, Silverlight, Dynamic Language Runtime, and Open Source (Miguel de Icaza)
• Microsoft Adds Open-Source Twist to Silverlight
• A conversation with John Lam (Jon Udell) points out that the DRL-based Ruby can’t run Rails
• At Mix07, is Microsoft bottom-trolling for developers with weak knees?
• Silly Season – wonderful rant at Dive Into Mark about Silverlight and Apollo

Although I am certainly happy to see Adobe moving in the direction of open source, it is good to more closely at the overall picture: what is being open sourced and what is not, which is exactly what Burnette does.

I guess it’s really just a question of “getting it” relative to others. The Flash player is still a closed platform, but at least it is available for Linux, unlike Silverlight.

</update>
—
Adobe seems increasingly to “get it” when it comes to enabling the modern web application environment, leveraging the strengths of the Flash player on all those dekstops, and allowing enough openness for creativity to flourish.

The latest example of which is the announcement this morning that they have open sourced the Flex SDK – compiler, libraries, and all. (Everything but the Eclipse-based IDE, which remains under a commercial license).

In the following video from the PodTech network, Ely Greenfield and David Wadhwani discuss the announcement with Robert Scoble:

Related links:

• Adobe to Open Source Flex (Adobe Labs)
• Adobe to Open Source Flex (press release at Yahoo! Finance)
• Adobe to Open Source Flex (at John Newton’s Content Log)

or ?

Adobe wants you to believe that the name Apollo is a reference to the Apollo project, the series of NASA missions aimed at landing a man on the Moon and returning him safely to Earth, a goal set by JFK that’s the point of the Apollo icon, with it’s orbital circle.

But I’ve decided the codename “Apollo” (Kevin Lynch has said that there will be a real release name which is different) is a disguised swipe at Ajax.

Ajax, in Greek mythology, was not a god, but a human hero and King. Interestingly, in the Illiad, he is the only major warrior who receives no assistance from the gods, suggesting “the virtues of hard work and perseverance.”

Microsoft called their Ajax platform (now more prosaicly known as ASP.NET AJAX) Atlas – a Titan and brother to Prometheus who held heaven and earth on his shoulders as a punishment from Zeus for leading the Titans in a revolt against the gods.

(Side note: This is the same Atlas who retrieved the Golden Apples of the Hesperides for Hercules, who tricked Atlas into taking back up the burden of the world on his shoulders).

So why does Adobe choose Apollo? Well, the god Apollo unites art and reason, and is the god of beauty, the sun, music, light, truth – the ideal of beauty. Perhaps Apollo plays in both senses here – rather than holding up the earth (like Atlas) Adobe’s Apollo is taking us to the moon and back, and providing beauty. Ajax was merely human, Apollo divine. Atlas tried to usurp the gods and was punished; Apollo brought order, music, and poetry.

Perhaps it’s time for an open source web/desktop framework named after Dionysus? (See Apollonian and Dionysian)

p.s. The Microsoft codename for what is now called Windows Presentation Foundation was Avalon. Why does Avalon sound familiar? It’s a mythic island associated with King Arthur – where Excalibur was forged, and where Arthur’s body rests. It’s also, though, famous for its beautiful apples. Microsoft admitting to the inspiration for their focus on improved graphics capability?

At AjaxWorld this week, I was amazed at the number of solutions for creating Rich Internet Applications. On the Open Source front, the usual suspects (libraries, frameworks, languages and tools) were mentioned:

• Dojo
• Prototype / Scriptaculous
• DWR
• Yahoo! UI Library
• Google Web Toolkit
• Symfony
• Zend Framework
• JSON
• The Eclipse Ajax Toolkit Framework
• OpenAjax Alliance
• OpenLaszlo
• Tibco GI (which went open source a few months back).

This is by no means a complete list of open source Ajax frameworks and applications – just those I heard mentioned or presented on at AjaxWorld. (Did no one mention JQuery?)

There were also a few “professional open source” solutions with companies behind them that were new to me:

• ICESoft Technologies – which releases ICEfaces in an open source version (MPL 1.1) and an Enterprise Production Suite version. They also make client side technology: ICEbrowser, ICEreader, and ICEpdf which can be evaluated but are not open source.
• Thinwire, an LGPL development framework for J2EE applications
  
• Helmi, a GPLv2 client framework

But there were also a number of proprietary solutions:

• Adobe Flex / Flash / Apollo
• Microsoft WPF / WPFe (they were not a sponsor, but mentioned in many presentations)
• JackBe
• BackBase
• Nexaweb
• Kapow
• Servoy
• Infragistics
• Telerik

And a lot of people raised as either a concern or a hope (depending on how you see things) the increasing presence of especially Adobe and Microsoft in terms of rich, web-based applications with increased drawing/animation/media handling capabilities.

A couple recent ruminations on the subject:

• The Open Web: What’s at Stake (Brendan Eich’s presentation at SXSW)
• The Open Web and its Adversaries (Brendan’s blog post about the presentation and open-ness)
• Brendan Eich on Mozilla and the Future of AJAX (Dare Obasanjo reacting to Brendan, arguing that openness is a “red herring” in the debate, which should be focused purely on the best technology)
• Rich application engines and user innovation (Jon Udell, who sees a need to bring web affordances like indexing and linking to video and rich formats)

And recent releases of note:

• OpenLaszlo 4.0 released: outputs to Flash or Ajax from the same codebase
• Adobe Apollo Alpha released: currently Windows and Mac OS X only – support for Linux in “future versions.”
• Forthcoming: FireFox 3.0

My take: we need to preserve as much as possible the open-ness that has made the web successful. That said, there may be some cases where a bit of proprietary-company-driven innovation helps raise the bar – after all, XMLHttpRequest was originally a non-standard Microsoft invention.

If those proprietary companies can find ways to make their innovations available to all (available in the sense of API level access and open standards, not just free like the Flash player is free) they will be welcome additions.

If they try to lock developers and consumers into a closed model, they will ultimately fail.

Just my $0.02.

The slides are available here:

• Building a Business Case for Ajax Applications (odp – Open Document Presentation)
• Building a Business Case fo Ajax Applications (pdf – Portable Document Format)
• Building a Business Case for Ajax Applications (ppt – PowerPoint Format)

It seems, though, that the basic “upload, transcode, display, embed” cycle YouTube made popular has become something of a commodity, in the sense that it is offered by a broad number of sites, with very little appreciable difference in quality. (Take a look at Chris Pirillo‘s comparison of Christmas Videos on “Soapbox vs. YouTube vs. Break.com vs. Vimeo. vs. Jumpcut vs. Blip.tv vs. Metacafe vs. Revver vs. iFilm” for example – or “YouTube vs. Google Video vs. Revver“).

But what does it mean for something to become a commodity?

There was a fantastic article by Michael Schrage in the Winter 2007 issue of the MIT Sloan Management Review on “The Myth of Commoditization” that I found really changed my way of thinking about the problem. (I wish I could link directly to the full article but it is for subscribers only).

Schrage opens with a great deconstruction of the toaster as the archetypal commodity, pointing out all the various changes in technology, marketing, and production of toasters throughout their history, and concluding: “The simple reality is that virtually no serious observer or participant in the multibillion-dollar global kitchen-appliance market would describe toasters as commodities.”

More importantly, he goes to discuss, what is meant by the perception that something has become a commodity is a lack of differentiation leading to intense price competition. However, there may be a more important message in that set of circumstances:

Intense price competition may not signal the prolific presence of substitutable commodities but an arid absence of unique innovation. . . . That signal presents a clear and present incentive for innovators and entrepreneurs to innovate in order to differentiation; to identify hidden or untapped potential for new value creation.

Powerful stuff. Is a commodity market a sign that we’ve given up on innovation?

If you look at the hundreds and hundreds (maybe we’re in to thousands by now) of user-uploaded-video sites, there is a “clear and present incentive” for innovation.

If all the “upload -> transcode -> display -> embed” vendors took this call to innovate seriously, what might they create?

If you’re not familiar with Apollo, it is a cross-platform (purportedly Windows, Mac OS X, and Linux) application which will run applications developed using HTML & Ajax as well as Flex/Flash applications: a rich internet application container of sorts. It’ll also understand the PDF format and be able to open PDF documents.

The interesting challenge, I think, is whether Apollo, or something like it, could replace the web browser as the fundamental container for internet applications. (A corollary question: if it could, would that be a good thing?)
As a desktop application, the Apollo container can add access to the local file system, as well as a mature model for online/offline connectivity (for applications to function in partially connected mode). Apollo could also offer the application developer more control over the “chrome” or “skin,” which browsers have traditionally kept under user control.

However, it seems like a step backward to revert to the application container model when the web browser has been doing quite well, thank you. Installing the Flash plugin is one thing, but having in essence a flash-plugin-on-steroids that can also do HTML and Ajax starts to seem like a web browser replacement. Do we need another?

Will users find the additional functionality of Apollo apps compelling enough to run them alongside the browser?

Unfortunately the beta release is now said to be early 2007 – they used to say late 2006. So we’ll have to wait and see. (Maybe they need to open source the whole thing so we can get it on schedule – it is using WebKit already).
You can sign up to be notified when the beta is released, or get more info about Apollo at Adobe Labs.

(Kevin Lynch was also on Talk Crunch December 16 2006: Here Comes Apollo – at which point he said Apollo would run first on Windows and Mac, then they would work on Linux after Flash Player 9 was done.)

Got an invitation code this weekend, just as I was getting up to speed on using my new Samsung Blackjack phone. Ah, the joy of synchronicity.

What Hey!Watch does is allow you to transcode video – translating it from one format to another.

In and of itself, that’s nothing to write home (or blog) about. But, they’ve added a number of features that I think are remarkable.

First and foremost, in addition to uploading video from your hard drive, you can point Hey!Watch at a url, or an RSS Feed with enclosures.

What this means is that you can “pull” videos from YouTube, MetaCafe, and many other sources – including video podcasts, or other feeds which are regularly updated. Point Hey!Watch at an RSS feed that has video enclosures, and it automagically discovers the videos, including updating when new ones are posted.

Second, it offers and incredible number of ingest and output formats – so it can take the Flash-based videos from YouTube and create WMV or MPG videos.

Finally, you can subscribe to an RSS feed of your encoded (really, transcoded) videos – so any video you’ve added to the system, via upload, via pointing to a url, via an RSS feed, gets added to your transcoded videos and published to that RSS feed. You can also hit a web page with thumbnails of all your transferred or transcoded videos, if you prefer – and download / delete them.

This is the right way to do transcoding in a Web 2.0 world.

The only thing not completely clear to me (my fault for not reading closely the terms when signing up) is what the revenue model is. I know I have a “watcher” level account for some period of time but I don’t have a clear picture of what all the different levels include, which are free (and which will continue to be free) and what the costs are.

One feature that caught my attention was a piece in Information Week titled Under Construction.
Could have been called “currently in Beta” of course, to be more in line with the Web 2.0 meme,
but overall it’s a pretty decent piece, pulling together segments on the evolving infrastructure of Web 2.0 applications in terms of:

• Scale
• Content Management
• Security
• Lightweight Development
• The User Experience
• Communities

As well as an Interactive Timeline.

The piece on “Content Management” is probably the strongest of the bunch, noting that “what makes content management more difficult for many Web 2.0 companies is the need to deal with user-generated material,” while the major content management systems aren’t designed to handle high volumes of intake and meta data from external users.
Most content management systems were architected and programmed for a world in which people inside the firewall create content, and those outside the firewall consume it. The article quotes Jesse James Garrett on this: the Web 2.0 “definition of content management was completely outside what the vendors were considering when they created their software.”

The section on “Lightweight Development,” on the other hand, stretches credulity to claim that:

Two popular options–Ruby and Flash–are similar to Ajax, the lightweight, browser-based combination of JavaScript and XML on which Google Maps and other interactive sites are based. Unlike Ajax, which is relatively new, Ruby and Flash are Web site building technologies with mature toolsets.

Other than both being four letters, in what way is Ruby “similar to” Ajax?

I assume the attempt is to identify all three as “lightweight development frameworks” – though how does Flash fit into that model? Is Flex and its MXML really a lightweight framework?
The real point seems to be just to link the examples – he’s trying to talk about BackChannelMedia’s site and the Nike Store – the former is developed in Ruby, the latter in Flash (really, one assumes, it’s developed in Flex).
Second, in what sense is Ajax new compared to Ruby on Rails? As far as I can remember, Rails went 1.0 in late 2005, and was only publicly available in mid 2004 at some point.

Nevertheless, the article overall does a pretty decent job of explaining how all these various changes are linked together into a broader paradigm shift.

(Yes, I’m sure I’m not the first to make the comparison between “Under Construction” and “Perpetual Beta” – the title was a cheap excuse to use “under construction man” in my blog).

There’s a tour of the new features or you can go directly to Toyland and start creating your wishlist by voting yes or no on the toys.
Some interesting functionality inside women’s apparel (highlighted in the tour) which hasn’t been leveraged throughout the site yet, including an add-to-cart that doesn’t interrupt the shopping flow and live color swatches.

Worth a persual even if you’d never admit to buying clothes from Walmart.

Read the announcement on the Penguin.SWF blog or the release notes, or download it from here.

(Make sure what you’re downloading is the beta update – if you go off on the path to download released versions you’ll end up with Flash 7).

I’ve only tried it on a few sites I know require Flash 9, but so far it is functioning perfectly for me in Ubuntu Dapper with Firefox 1.5

Two excellent examples of how rich internet applications (in this case Flash based) can revolutionize the shopping/merchandising experience on the web.

Both are from Ikea, and not available (so far as I can tell) in English. (Not that their regular e-commerce site in the US isn’t delightful, but it seems a bit less playful than these).

You’ll need Flash installed (apparently “Laddar” means “Loading” in Swedish) and you should have your speakers on, for the total ambience.

If shopping were always this fun I might even buy things.

David Temkin, the founder and CTO, did most of the presentation, joined by Amy Muntz to talk about how people can get involved as contributors to the OpenLaszlo project.

If you’ve never heard of OpenLaszlo, the basic value proposition is (from their site):

OpenLaszlo is an open source platform for creating zero-install web applications with the user interface capabilities of desktop client software.

OpenLaszlo programs are written in XML and JavaScript and transparently compiled to Flash and soon DHTML. The OpenLaszlo APIs provide animation, layout, data binding, server communication, and declarative UI. An OpenLaszlo application can be as short as a single source file, or factored into multiple files that define reusable classes and libraries.

The “and soon DHTML” part is the newest part, and that was one of the things they demo’d.

The company was founded in 2000, and converted the whole project to Open Source in 2004. They draw revenuye from training, custom design and development, as well as some commercial extensions to the core platform.

Temkin started by going over the basics of Rich Internet Applications (RIAs) and their business benefits – the experience of a desktop application, but with the ease-of-deployment of a web application.

Some of the applications he demonstrated, which use OpenLaszlo in the interface tier:

• Laszlomail.com
• AllState Insurance (widget in the right nav with accordion panels for customer care, claims, quotes)
• Gliffy
  
• Pandora
• Barclay’s iShares (Look for the performance charts)
• IBM Innovation

The discussion ranged over a variety of topics – Temkin did a great job of answering questions during the presentation-in-progress without getting pulled entirely away from what he needed to get through.
One interesting point was the question of partially connected (or occasionally connected) clients – right now, when you use Gliffy, for example, if you lose your internet connection in the middle of working on a drawing, the behavior you’ll get is at best undefined – most likely complete failure when the client’s requests start timing out. Temkin mentioned that Laszlo has an interest in this question but not much more to add other than that they will be looking into solutions.

He also pointed out, in the Pandora example, the value of leveraging the Flash player’s ability to handle streaming video and audio directly. In the AJAX world one needs a plugin for these media types (of course, Flash is already a plugin, but relying on only one, monolithic run-time environment would arguably be simpler than dealing with multiple layers).

Lots of folks asked about how developing in OpenLaszlo differed from developing in Flash. In essense, the OpenLaszlo environment is more like Flex than traditional Flash: XML based language which gets compiled into an SWF. This means no more “timeline” or “stage” or any of the other design-based components that plain-old-Flash was saddled with. But, as someone in the audience pointed out (and Temkin agreed) to really make the most of an OpenLaszlo application you need both designer and developer input. Just as PageMaker didn’t automatically make good graphic designers of everyone, an XML-based declarative markup language and set of components won’t turn developers into designers.

The code for OpenLaszlo applications is written in LZX. Those *.lzx files are then compiled into an SWF. OpenLaszlo supports both “solo deployment,” in which the .swf file is just put on a plain-old web server, and “proxy deployment,” in which OpenLaszlo pieces (a servlet) gets installed on the server. (Architecture). Temkin noted that the pieces which require the servlet deployment are SOAP, Java RPC, format transcoding for media, and persistence / storage.

My favorite part of the presentation was a slide that showed the continuum of AJAX type applications: at the far left is the “mostly static, view based” html site which just adds a small interactive widget – it’s basically a webpage with some AJAX goodness grafted on. At the far right is a complete application – a desktop or client-server like application which just happens to be running inside a browser, but could just as easily be a Java WebStart app, or a Win32 app. Temkin pointed out that if all you’re trying to do is add some interactive elements to a mostly traditional web application, using an Ajax library will make more sense than an overall framework like OpenLaszlo (or, though he didn’t say it, Flex). If, however, you’re trying to create an entire application, a full on framework makes more sense.
Finally, he got to the demo of OpenLaszlo 4.0, codenamed Legals, which is the version capable of generating either AJAX (DHTML) or Flash (SWF). The demo application, LZPix, shows off identical functionality in a Flash interface and an AJAX inteface, both generated from the same LZX code.

This created lots of discussion around why Laszlo Systems originally focused on the Flash player as a “browser-based run-time engine,” and why they were now adding Ajax as an alternative. The crowd seemed rather slanted (no objective evidence here – just my impression) to the Flash side; so much so that the question quickly shifted to “Why wouldn’t you just output Flash” to which it wasn’t clear Temkin felt there were any real well-founded answers.
If you start from an acceptance of the notion that 97 or 98 percent of all browsers connecting to the internet “have Flash” this is an easier argument to understand. (Of course, that argument generally glosses over what *version* of Flash people have, but since OpenLaszlo outputs Flash 7 compatible swfs that may be less of an issue for them than for the Flex 2.0 users). The back button can be trapped here just as it can in a well-architected AJAX application, keyboard navigation can be provided, etc.

So why would anyone use AJAX as a runtime rather than the Flash Player?

• HTML support within Flash (at least v7,v8) is awful. If the app will handle lots of display of html blocks, outputing AJAX makes more sense than wrapping that html inside Flash. If you’re mashing together things you control with HTML coming from other services, AJAX may be more effective.
• Performance may be better for somethings. The LZPix demo is noticably faster in AJAX than in Flash – though this may be a quesiton of what particular functions your app uses most often. (Note that Adobe’s demos of Flash 9 player claim it is significantly faster than AJAX functions, but again they control the testbed).
• Support for environments lacking the Flash player.
• Accessibility – not that there aren’t challenges with Ajax and accessibility as well.

In the long run, perhaps the most interesting question is why OpenLaszlo is going to such lengths to provide an AJAX output if they feel Flash output is more effective. To that the obvious answer seems to be marketing – the more potential Laszlo users the better, and if AJAX output is the hottest thing since sliced bread, Laszlo had better have it.

What do you think? Is resistance to the Flash plugin just a carryover from the days of “skip intro” web sites and annoying, animated banner ads?

Finally, I should also mention that Amy Muntz went through some of the basics of the community, the contributors’ license, and they multiple ways people can get involved. It’s important to remember that this is, and has been since 2004, an open source platform and there are many opportunities to contribute to its evolution.

1. Flex 2 SDK, FlexBuilder, Flex Data Services, etc. Basically the whole 2.0 line of Flex, which provide an environment (IDE), packaged components, and a compiler which outputs .swf format, to be deployed to a web server and interpreted by the Flash player in the user’s browser
2. AMFPHP (a non-Adobe open source project) for sending objects back and forth between PHP on the server and Flash on the client without the need for serialization/deserialization. (No current support for nested objects, but an array of objects can be returned directly).
3. Flex/AJAX Bridge (an Adobe Labs open source project, ) for exchanging messages between JavaScript in the Browser and ActionScript inside the Flash player (or your Flex application which is running as an SWF in the Flash Player in the Browser). Google Finance actually uses this when you are looking at a stock chart like this one, to highlight the news stories on the right if you click on a letter in the chart and vice-versa. (I wonder what Grease Monkey scripts could do here – since they can now alter the Flash movie as well as the DOM of the page).
4. Apollo, which he described but did not show – basically an “.swf runner” which will let users download Flex applications (as .swf files) and run them in a desktop environment without communication back and forth with a server. Will also probably serve as a host environment to PDF files, and potentially (Potter was less committal here) AJAX applications. A developer preview should be coming “later this year.”

A few notes:

The Flex 2 “platform” as a whole has some pieces that are free (as in beer, not speech) and some pieces that require paid licensing. The IDE, built on top of Eclipse, will cost “under $1,000″ and perhaps even “well under $1,000,” but likely much more than $0.

Flex 2 output .swf files require Flash 9 player on the client side. (This is the player formerly known as Flash 8.5). While Adobe has been strong (or Macromedia was and I see no reason to expect Adobe to change it) at getting new versions of the player deployed quickly, in the immediate future this will limit the audience.

The demos showed strong performance gains for Flash-based rich applications as compared to Ajax – ~2.6 seconds for a call to retrieve 1000 rows by 7 columns of data in Flash versus ~9 seconds in “Ajax.” (Not sure what framework / js code was used). Obviously Adobe’s put a lot of work into the Flash 9 player, and it makes sense that it would be fast for optimized operations. Of course this doesn’t mean your app would be faster in Flex, but it was interesting to see Adobe starting to make that argument.

The Flash player can also save locally on the browser’s host OS, up to 100k without user permission – and the user can set that up to 10MB or “unlimited.” However, this space is shared amongst all swfs run in that browser. (The data in the space can’t be accessed across swfs, but everyone’s taking space from the same pool – that could make debugging problems “in the wild” intersting).

He also briefly mentioned the Spry framework, which is an AJAX toolkit Adobe released, but said that in his opinion AJAX is just a stepping stone on the way to better dynamic interfaces (in Flash, XUL, XAML, or other technologies).

Mike Melanson, the blog’s author, says he “may” ask for input on issues.

I’m hoping that means development of a Flash player for Linux is actually occuring, to the point where it has issues on which input could be required.

So far, there’s only one post (the “origin story”) and 73 comments – I’m assuming that ratio will even out over time.