Tim Anderson’s ITWriting

The route to dizzying riches in this industry is to own the platform. Look no further than Microsoft, which not only sells the operating system, but also dominates the applications which run on it, from Microsoft Office on the desktop, to server products like Exchange and SQL Server, and network management software like System Center. Anyone can build applications for Windows, and plenty of third-parties have done so successfully using its free SDK (Software Development Kit), but somehow it is Microsoft that profits most.

Microsoft is still doing its thing, but attention is turning to the next generation of Internet-based computing. I touched a nerve when I asked Google’s Dion Almaer about Adobe Flash: it’s not open enough for Google, he told me. I put this to Adobe’s Dave McAllister, director of standards and open source, who assured me that Flash is all-but open, excepting (ahem) the source code to the runtime. Then he surprised me (considering he is an open source guy) by accusing Mozilla of bad faith over Tamarin, the source code to its ActionScript 3 runtime and just-in-time compiler, and remarking that Sun’s efforts to open source Java had mainly helped its competitors. I wrote this up for the Reg.

The problem is that these companies want the best of both worlds: the widespread adoption and community contributions that open source can generate, but the control and profit that comes from owning the platform.

If you can’t own the platform, the next best thing is that nobody owns the platform, which is why IBM worked to hard to get Sun to open source Java, and deliberately muddied the waters by sponsoring the Eclipse tools platform and alternative Java runtimes and GUI libraries.

Why is Google wary of Flash? Simply, because it is risky to build your own application platform on a runtime that belongs to another company. It is not enough for Adobe to say it will never charge for the runtime, any more than it is enough for Microsoft to give away the Windows SDK. Google is watching Adobe, and seeing how it is building online applications like Buzzword which competes with its own Google Docs. Companies with their own platform ambitions (Apple also comes to mind) are more likely to be averse to Flash. Oh, and look who else is building its own alternative to Flash? Yes, Microsoft with Silverlight.

Like Google, Mozilla is trying to build a browser platform that has less need of proprietary plug-ins like Flash. Although I was surprised that Adobe’s McAllister said Mozilla was using its open source contributions in the wrong kind of way, seemingly missing the whole point of open source, I was not surprised to find tensions. I quizzed Mozilla’s John Resig on this exact subject one year ago, when I wrote that Adobe and Mozilla were on course for collision.

As McAllister points out, open source also has risks, particularly the danger of fragmentation and multiple incompatible versions. Maybe Flash is better as closed-source. Still, let’s not pretend it is really all-but open source. The real issue is who owns and controls the platform, and in this case it is definitely Adobe.

Advertisement Click here for special offers including free magazine subscriptions,white papers and ebooks.

Very much a first look – I’ll have much more to say about this software.

An email from Adobe alerts me to the release of AIR 1.1 for Linux beta, which I installed on my laptop which runs Ubuntu.

Installation is not quite so smooth as on Windows; you have to set execute permissions on the download before running it. It took only a moment though, and I soon had twhirl up and running, which is the only AIR application I use with any regularity.

The release notes say that all features are available except DRM. If you want transparency support, you must have a compositing manager like Beryl, Compiz or Compiz-fusion installed. You can also download a Linux SDK.

I realise that most of the world only cares about Mac and Windows clients, but I like today’s Linux desktop and kudos to Adobe for supporting it with AIR.

Here at Developer Day, I couldn’t decide between the sessions on Android and App Engine, so ended up hearing Ajaxian Dion Almaer talking on the state of Ajax. Almaer also works for Google on its developer programs.

The talk was a bit fuzzy and high-level for my taste, though I enjoyed his tour of JavaScript libraries.

Following the talk I asked him why Google makes little use of Adobe Flash (which he hardly mentioned). He said it would like to, but did not regard it as an open platform. I asked him what Adobe would need to do to change that, and he said that the key things would be to open source the Flash player, and to give the community more influence over future Flash development.

Might this happen? Almaer said that it is a subject of ongoing discussion with Adobe. The implication is that if Adobe makes these changes Google will start supporting and using it more actively.

It will be an interesting subject to take up with Adobe when I next have that opportunity.

I’m not at the Office 2.0 conference, sadly, but fortunately for non-attendees the organizers have done a great job of making the content available online in a timely manner. Aside: I love the way this site includes social networking features, like the ability for users to comment on sessions beforehand, so that they can influence the content; and the way videos have appeared on the same day as they were presented.

One of the first things that caught my eye was Adobe’s Genesis. I watched the presentation by Matthias Zeller. As I understand it, Genesis is an AIR application plus online services, that enables enterprise mashups, organized into workspaces. AIR (Adobe Integrated Runtime) is a way of using the Flash runtime on the desktop.

What’s in a Genesis Workspace? A collection of “tiles”, actually Flex applets, which can hook into other enterprise or web applications. It is a good fit with SAAS (software as a service) providers such as Salesforce.com. There is also a web browser tile (presumably based on WebKit), enabling the inclusion of any browser application; and a file repository tile that contains documents, using some of the functionality we have already seen in Acrobat.com. The idea is that these workspaces are easily created using drag-and-drop. The real value comes when they are shared online, through Adobe’s hosted services, enabling communication and collaboration.

Zeller says the Genesis client will be free, with monetization coming from subscriptions to hosted services and tiles; third-parties will also be able to market tiles for the system. There is an online slideshow here.

This is only my brief first impression; please follow the links for more detail. I found it interesting on several levels: a new approach to the cloud; a business use for AIR; and also this comment in the presentation, “Adobe-quality aesthetics for the enterprise”.

This was the conclusion of an EcmaScript meeting in Oslo last month. Specifically, as Brendan Eich explains, three features - packages, namespaces and early binding – were considered too heavyweight unsuitable for a browser scripting language. Here is Eich’s “Executive summary”:

The committee has resolved in favor of these tasks and conclusions:

1. Focus work on ES3.1 with full collaboration of all parties, and target two interoperable implementations by early next year.

2. Collaborate on the next step beyond ES3.1, which will include syntactic extensions but which will be more modest than ES4 in both semantic and syntactic innovation.

3. Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.

4. Other goals and ideas from ES4 are being rephrased to keep consensus in the committee; these include a notion of classes based on existing ES3 concepts combined with proposed ES3.1 extensions.

This means that the evolution of JavaScript is now on a new path, focused for now on a more modest enhancement to the language called EcmaScript 3.1.

Given how loudly Eich protested about EcmaScript 3.1 last October, it is a surprising turn of events. Was Eich convinced by the arguments of Microsoft and Yahoo in support of a more lightweight JavaScript?

What this means is that JavaScript 2.0 won’t happen as previously envisaged. John Resig:

… you can forget a lot of what you learned about ECMAScript 4, previously. Many of the complicated concepts contained in the language have been tossed. Instead there is a considerable amount of effort going in to making sure that new features will be easily duplicable through other means.

Eich and Resig are keen to stress that JavaScript will still be a highly capable language. Still, the obvious conclusion is that this will be good for plug-ins which support more powerful languages: Adobe Flash, Microsoft Silverlight, Sun Java or Java/FX. Personally I’m disappointed.

It is also presenting Adobe with a tricky problem, as it implemented much of an earlier specification for EcmaScript 4 in ActionScript 3. Rather than being a standard language, as Adobe had planned, it looks like this will now be more of an Adobe language. I doubt this will have much practical impact on developers.

PS Brendan Eich has commented below.

The BBC’s streamed catch-up broadcasting, iPlayer, is about to be upgraded to the high-definition H.264 standard, according to this post, from the BBC’s Head of Digital Media Anthony Rose.

He says that the “Play high quality” option will be available “from this week”, though I couldn’t see any sign of it on a brief sampling of available content.

The question: where does this leave the download service, based on peer-to-peer file sharing? This is the thing that caused me considerable hassle this time last year, and which also drew criticism because it is Windows-only.

By contrast, the Flash-based embedded video seems to have performed as smoothly as Flash usually does.

When Flash streaming was introduced, the BBC said that the download option would remain for higher-quality viewing, but with H.264 Flash that argument has little force. It is still comforting to have a downloaded file, in case your Net connection fails or becomes congested, but other than that there is little advantage. My guess is that it will wither. Supporting both must be expensive.

It is unfortunate for Microsoft, whose technology is losing out to Adobe’s at the BBC, particularly since Silverlight would probably have worked nicely in this context. Unfortunately the old iPlayer is not Silverlight, but based on Windows Media Player, known to be hassle-prone as well as being single platform.

A year or so a go I wrote a post called Adobe AIR: 10 reasons to love it, 10 reasons to hate it. Here’s the same kind of list for Microsoft’s Silverlight, based on the forthcoming Silverlight 2.0 rather than the current version. The items are not in any kind of order; they also reflect my interest in application development rather than design. It is not a definitive list, so there are many more points you could make – by all means comment – and it will be interesting to have another look a year from now when the real thing has been out for a while.

This Silverlight developer chart is available in full on Brad Abrams’ blog here, or in Joe Stegman’s Deep Zoom version here.

The pros…

1. The Silverlight plug-in means developers can target a single, consistent runtime for browser-based applications, rather than dealing with the complexity of multiple browsers in different versions. You also get video and multimedia effects that are hard or impossible with pure HTML and JavaScript; though Adobe’s Flash has the same advantages.

2. Execute .NET code without deploying the .NET runtime. Of course, the Silverlight plug-in does include a cut-down .NET runtime, but instead of dealing with a large download and the complexities of the Windows installer, the user has a small download of about 4MB, all handled within the browser. In my experience so far, installation is smooth and easy.

3. Performance is promising. Silverlight comes out well in this prime number calculator, thanks no doubt to JIT compilation to native code, though it may not compare so well for rendering graphics.

4. Support for Mono (Moonlight) means there will be an official open source implementation of Silverlight, mitigating the proprietary aspect.

5. Silverlight interprets XAML directly, whereas Adobe’s XML GUI language, MXML, gets converted to SWF at compile time. In fact, XAML pages are included as resources in the compiled .XAP binary used for deploying Silverlight applications. A .XAP file is just a ZIP with a different extension. This also means that search engines can potentially index text within a Silverlight application, just as they can with Flash.

6. Third-party component vendors are already well on with Silverlight add-ons. For example, Infragistics, ComponentOne and DevExpress.

7. Take your .NET code cross-platform. With Macs popping up everywhere, the ability to migrate VB or C# code to a cross-platform, browser-based Silverlight client will be increasingly useful. Clearly this only applies to existing .NET developers: I guess this is the main market for Silverlight, but it is a large one. The same applies to the next point:

8. Uses Visual Studio. Microsoft’s IDE is a mature and well-liked development environment; and since it is also the tool for ASP.NET, you can use it for server-side code as well as for the Silverlight client. For those who don’t get on with Visual Studio, the Silverlight SDK also supports command-line compilation.

9. Choose your language. Support for multiple languages has been part of .NET since its beginning, and having the .NET runtime in Silverlight 2.0 means you can code your client-side logic in C#, Visual Basic, or thanks to the DLR (Dynamic Language Runtime) Iron Ruby or Iron Python.

10. Isolated storage gives Silverlight applications local file access, but only in a protected location specific to the application, providing a relatively secure way to get this benefit.

The cons…

1. If Apple won’t even allow Flash on the iPhone, what chance is there for Silverlight?

2. Silverlight is late to the game. Flash is mature, well trusted and ubiquitous; Silverlight only comes out of beta in the Autumn (we hope) in the version we care about – the one that includes the .NET runtime - and will still lack support on mobile devices, even Windows Mobile, though this is promised at some unspecified later date.

3. The design tools are Expression Blend and Expression Design – but who uses them? The design world uses Adobe PhotoShop.

4. While having solution compatibility between Expression Blend and Visual Studio sounds good, it’s actually a hassle having to use two separate tools, especially when there are niggling incompatibilities, as in the current beta.

5. No support for the popular H.264 video codec. Instead hi-def video for Silverlight must be in VC-1, which is less common.

6. It’s another effort to promote proprietary technology rather than open standards.

7. Yes Linux will be supported via Moonlight, but when? It seems likely that the Linux implementation will always lag behind the Windows and Mac releases.

8. Silverlight supports SOAP web services, or REST provided you don’t use PUT or DELETE, but doesn’t have an optimized binary protocol like Adobe’s AMF (ActionScript Message Format), which likely means slower performance in some scenarios.

9. Silverlight is a browser-only solution, whereas Flash can be deployed for the desktop using AIR (Adobe Integrated Runtime). Having said that, yes I have seen this.

10. You have to develop on Windows. This is particularly a problem for the Expression design tools, since designers have a disproportionately high number of Macs.

Adobe’s Andrew Shorten contacted me following my piece on consuming .NET SOAP with Flex.

He mentioned two free products which integrate Flex with .NET.

Fluorine “provides an implementation of Flex/Flash Remoting, Flex Data Services and real-time messaging functionality for the .NET framework.”

WebORB from Midnight Coders “supports Action Message Format (AMF) version 0 and 3 and can be used to process Flex and Flash Remoting requests. Additionally, WebORB provides an implementation of the RTMP protocol and supports the following real-time messaging and streaming features: Flash Video streaming, video recording, data push, server-to-client invocation and remote shared objects.” There are also implementations of WebORB for Java, PHP and Ruby.

These look useful if you want to take advantage of the faster AMF protocol or use other features like RTMP. The disadvantage: more server-side gunk.

Verity Stob’s Web 2.0 app diagram is worth a look.

So is it back to plain old HTML+forms then? That won’t do either; your app will look a decade old, and offline will never work.

This is why the current RIA wars are fascinating – particularly since Apple seems averse to runtimes like Flash, Java or Silverlight on its iPhone.

Which leaves what? JavaScript, hélas.