Photo by Mike Johnston - http://www.flickr.com/photos/mikejsolutions/3078513728/

Just found this long overdue review of Ajax and PHP: Building Modern Web Applications – Second Edition sitting in a drafts folder – looks like I never published it. (Full disclosure – Packt sent me a review copy).

This is the successor to the wildly popular Ajax and PHP: Building Responsive Web Applications, which came out back in 2005. The authors of this edition are Bogdan Brinzarea-Iamandi, Christian Darie, and Audra Hendrix. (Brinzarea-Iamandi was also one of the authors of the first edition).

This is a really useful book for the right audience, covering:

• Simple PHP, including connecting to MySQL
• Basic MySQL and relational databases, including some basic queries
• JavaScript, including a discussion of object oriented JavaScript and the benefits thereof
• JQuery, which is rapidly becoming the dominant JavaScript framework (and is now included in applications like WordPress and Drupal)
• Debugging approaches and techniques, including profiling
• Cross-site scripting exploits and how to mitigate them
• Cross-domain ajax calls using server proxies, Flash, iFrames, and JSONP

In other words, although it does use Ajax as the ostensible subject at hand, in order to explain how Ajax works in the context of real web applications, the book ends up covering a wide ground in a rapid fashion. The book culminates in two practical examples: a chat application and a data grid, both using JQuery, PHP, and MySQL together in familiar patterns.

More experienced readers might be frustrated by how quickly the book moves through these topics. Trying to cover, for example, “Object oriented programming concepts” in four pages requires a very concise definition and not a huge set of examples or illustrative excercises. The book also doesn’t stray outside the LAMP stack, to talk about Ajax in Microsoft.NET, Java, Python, or Ruby applications, and doesn’t address other relational databases, let alone the whole NoSQL movement. There’s also no HTML5 discussion, but you have to remember the book was published in December of 2009.

One decision which struck me as odd, but may be a reflection of my personal experience, is that they cover (in an appendix) setting up XAMPP for Windows and Linux, but for Mac OS they send you to a web tutorial. Have you been to a web dev conference lately and seen how prevalent the Apple logo is? I get why you’d want to focus in and not try to cover all the cases, but I think based on my experience I might out Mac instructions first.

But coming to this book expecting detailed architectural discussions across multiple platforms is looking for wisdom in all the wrong places. Peruse the table of contents at the PACKT site and see which category you (or whomever you’re buying the book for) might fit in.

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.

Unfortunately we weren’t able to record the audio of the whole presentation, but the slides themselves are now available on the Optaros site: “Rich Internet Applications: The What, Why, When, and How” (pdf, 3.37 MB).

It’s under a creative commons license.

My favorite pearl of wisdom from that talk: The best thing about JavaScript is that there have been no new design mistakes since 1999 (when spec was last updated).

In addition to being highly knowledgeable (Brendan Eich called him the Yoda of Lambda Programming and JavaScript, he “discovered” JSON) he’s also entertaining, funny, and thought provoking.

In this video, after about 10-12 minutes of broad background on why the fundamental nature of security on the web is broken, he dives into the specific problem of mashups, the same origin policy in JavaScript, the global namespace and shared DOM, and suggests a method for using Google Gears to craft a solution.

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.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

In parallel, a group of developers working on open source PHP projects have created GoPHP5, a site and community of projects all of which have agreed to drive PHP5 adoption. In order to be listed on the site, the project must:

Make an announcement on your site that by February 5, 2008 you will accept PHP 5.2 features into your codebase and will no longer provide support for lesser PHP versions. (versions or branches of your software already released by that date may continue support for older versions; this resolution applies only to new development.)

The idea is that unless a certain critical mass of key projects begins to require PHP 5, most shared web hosts won’t upgrade the version of PHP they make available to their users. Because the web hosts still run PHP 4, the developers of PHP projects still have to support PHP 4 – but so long as the developers continue to support PHP 4 there is no incentive for the hosting providers to upgrade:

It is a dangerous cycle, and one that needs to be broken. The PHP developer community has decided that it is indeed now time to move forward, together. Therefore, the listed software projects have all agreed that effective February 5th, 2008, any new feature releases will have a minimum version requirement of at least PHP 5.2.0. Furthermore, the listed web hosts have agreed that effective February 5th, 2008, they will include PHP 5.2 (or a more recent version) in their service offer.

WordPress, however, is not (and will not be) one of the projects on this particular PHP bandwagon. Ticket #4591 has been marked closed, wontfix:

This has been brought up probably half a dozen times, and our position is the same.

* PHP5 does not yet have sufficient penetration. On many hosts where it is available, it is not the default.
* We’re not going to turn WordPress into a protest piece at the expense of our users.
* We’re not going to set a date for the end of PHP4 support when there is no evidence to suggest that the hosting landscape will be any different on that date.

Matt Mullenweg also weighed in on the issue on his blog, arguing that:

Now the PHP core team seems to have decided that the boost their failing product needs is to kill off their successful one instead of asking the hard questions: What was it that made PHP 4 so successful? What are we doing to emphasize those strengths? Why wasn’t PHP 5 compelling to that same audience? Are the things we’re doing in PHP 6 crucial to our core audience or simply “good” language problems to solve? Will they drive adoption? How can we avoid releasing (another) PCjr?

(Tell us how you really feel, Matt.)

While I can understand the desire of the GoPHP5 folks to encourage web hosts to make available new language features, I have to say ultimately Matt’s right on this one. Explicitly choosing not to provide support to a group of users in order to force adoption of a new version is putting the cart (developer interests) before the horse (user needs).

That said, how can the PHP community get PHP5 more broadly deployed? (And deployed as the default at hosts which need to provide support for both 4 and 5, which will be the case at many shared hosts)? What do you do when the older version is successful people don’t see a good reason to migrate to the newer version?

I remember the bad old days of Netscape Navigator 4.x, and how terribly long it took for the number of users on NN 4.x to reach a low enough level that they could be “unsupported” from a web development point of view. Ajax would never have taken off so widely as a technique had it not been so easy to talk about supporting “All major browsers, 5.x or later” – dropping the old Netscape stack and supporting only Mozilla based browsers (and that MS thing). But that happened more or less accidentally – no one continued to develop NN 4.x as the company failed, and new and more compelling options (Firefox, Safari, Opera) appeared.

How do we get beyond PHP4 without leaving users behind?

More generally, how do you crank the adoption cycle to move faster, without forcing end-of-life?

Ubuntu‘s LTS releases “will be supported with security updates for 5 years on the server and 3 years on the desktop” – part of a deliberate strategy to reduce user’s risk of obsolescence and increase adoption of Linux. But PHP5 is already three years old – PHP4 was launched in May of 2000!

(Update: Just coincidentally came across this: 4 Years Ago Today – Netscape Corporation Killed, Mozilla Foundation Born. – I thought netscape’s death was even longer ago than 4 years. How quickly time flies).

They discuss a project Optaros did with Swisscom Hospitality Services as an example of the impact next generation Internet applications can have customer interactions, as well as how we think such applications are most effectively delivered.

The presentations from the webinar are now available:

• David Douek, Product Management, Swisscom Hospitality Services: Swisscom Hospitality Services Room 2.0 (Case Study) (pdf|899.27 kB)
• Joel Gardet, Project Manager, Optaros: What it means to assemble next generation internet applications (OptAM) (pdf|4.05 MB)
• Bruno Von Rotz, VP Strategy & Research, Optaros: The Evolution of the online customer communication and interaction (pdf|3.46 MB)

Accompanying the beta site, they’ve launched a blog, Behind the Scenes at CNN.com, where they are encouraging discussion of the redesign.

It’s a great concept – specifically highlighting what the team is trying to accomplish in the redesign, and going beyond the constraints of carefully chosen focus groups under NDAs for a far more transparent and open forum.

Not all the comments will be terribly valuable, of course; the first comment on the first post says in its entirety: “It’s too white. Not enough color. print is too small. Make it more colorful like USA Today. com or MSNBC.com.”

But when all the comments are taken together, they will undoubtedly get insights and guidance from their most vocal constituents which will help guide their evolution, and which they would only have received too late (or not at all) under the old “design and build under a cloud of secrecy, then reveal only when it is all complete” approach.

They’re also explicitly working on what Dermot Waters characterizes as “being a good web citizen” by pointing to local news sources and blog posts which are outside CNN’s domain.

The idea, which sounds almost self-evident but isn’t always well understood by online media sites, is that:

. . . by being a good web citizen, we fulfill our core mission by doing whatever it takes to help you get the full story — even if it takes you away from CNN.com. If we do that well, we believe you’ll keep coming back.

It will be interesting to watch the site (and the discussion about its goals and their fulfillment) evolve.

(In the interest of full disclosure, Turner Broadcasting is an Optaros client – but that doesn’t influence what I’ve said above except that I’ve had a chance to meet some of the folks behind the effort and know that they get it and mean what they say.)

• 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

Today Joyent announced the public release of Slingshot, a framework for (their words) obliterating the distinction between the web and the desktop.

Slingshot lets developers take Ruby-on-Rails applications and deploy them to desktops (Windows, Mac OS X).

Is it just me, or does the red rock in the slingshot graphic look a bit like the Adobe Apollo logo? Ok, so maybe not a direct version of the logo, but certain the Adobe Apollo red.

Is this a cheaper faster way to get to sent to the moon and back, or just another David vs. Goliath myth?

More on Slingshot, including a quick tour.

He’s posted a video of the talk he gave at the expo: “Creating Offline Web Applications Within the Browser.” It describes in quite a bit of detail how to use the Dojo Offline Toolkit to enable offline use of Ajax applications.

If you’re not looking for the tech details I still think the first 15-20 minutes is worth watching as he outlines why you might want offline web applications and what characteristics a good framework should provide for such apps.

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?

Today, TechCrunch announced “Zimbra Desktop to Launch: Full Offline Functionality” – saying the launch will be announced “later this week.”

The alpha appears to be available already: Zimbra on your Desktop.

According to TechCrunch:

Zimbra Desktop will be available cross platform (Windows, Mac, Linux) and cross browser (Firefox, IE, Safari). The Zimbra web application and all user data is stored on the client computer (the database is Apache Derby). Data is synced real time when in online mode.

Zimbra Desktop does not include drag and drop functionality into the browser (for, say, dragging an attachment into an email), although the company says it will be included in a future release.

All Zimbra source code, including Zimbra Desktop, is open source – I expect other web developers to be taking a close look at how they are architecting things.

They’re using Apache Derby to store data client side and then synchronize/replicate with the server.

This may be just the nudge I need to finally leave Thunderbird behind altogether – right now I use Zimbra when connected and then Thunderbird to pull down mail so I can have it when offline.

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.

It was crammed into one of the 25-minute sessions SXSW had in the afternoons (a 3:30-3:55 spot and a 4:05-4:30 spot each day) so the rapid-fire nature of it made good sense.

They showed a lot of code demonstrating features in JavaScript 1.6,and 1.7, but the time limit meant that the examples are typically fairly simple, standalone examples which show the syntax but not necessarily the value -  that is, they show you how an iterator works, not necessarily the best practices of how to use one.

I also wish they’d been able to spend more time talking about JavaScript 2.0, though perhaps that’s too in the future, or even the upcoming improvements in Prototype.js. (I know, just because Andrew works on prototype doesn’t mean I should I assume the talk will be about it).

That said, it’s a very clear, easy to understand tutorial on some of the language goodness in 1.6 and 1.7 – and the slides are available on Aaron’s blog.

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)

In it, Lionel Laské develops a (LGPL licensed) cross-provider API for drawing maps in web applications:

MyMap is the portable API I created to display maps in a web site with either Google Maps, Yahoo Maps, or
Microsoft Virtual Earth. Here is the pseudointerface of this API in JavaScript. Each function matches one of
the aforementioned features:

void MyMapGeocode(address, callback);
void MyMapInitialize (mapname, lat, lng, zoom, mode);
Object MyMapAddMarker (lat, lng, markertype, info);
void MyMapRemoveMarker(marker);
void MyMapSetZoom(zoom);
void MyMapGoto(lat, lng);
void MyMapTerminate();

I haven’t had time to try it out yet but it looks like a very nice abstraction layer providing the basic mapping functions across providers – it doesn’t take advantage of what each provider differentiates on, but focuses on what is core – ability to create maps, add markers, set zoom levels, and find locations.

The source is available from Dr. Dobbs Source Code Page – choose 2007 and then download 07003.zip (March 2007).

Scott Ambler’s “Agile Documentation Strategies” is also well worth reading, on the importance of good documentation within an agile process. (And no, agile doesn’t mean writing no documents).

Happy Birthday, AJAX! – Two Years Old Already
Yesterday marked the passing of two years since Jesse James Garrett posted online his seminal essay, ‘Ajax: A New Approach to Web Applications’ and then went offline, on a trip. What he came back to is now a part of Web 2.0 and Rich Internet Applications history: it was as if simply giving a handy name to the technique behind a new, richer web somehow catapulted it into being.

Does this mean Ajax will now be headed into the terrible twos?

According to Vincent Ianelli, who wrote the About.com page on the subject:

Characterized by toddlers being negative about most things and often saying ‘no’, the terrible twos may also find your toddler having frequent mood changes and temper tantrum.

The last thing I need is for my web applications to start throwing temper tantrums – though I guess I would bring new meaning to setTimeout(); (bad javascript joke, sorry).

Here’s my take on the recommended tips for the terrible twos, translated for developers:

• Have a regular routine
  • In other words, be disciplined about your approach to Ajax in application development – do things the same way each time. (This is also a good plug for using a mature framework, which encourages a routine)
• Offer limited choices
  • Just because you can doesn’t mean you should. Rather than ajaxifying everything in your web app, start small with a few incremental improvements and move out from there.
• Learn to set limits . . . and don’t be surprised when your toddler tried to test these limits
  • Remember that your javascript is exposed to the client, and can be tampered with – don’t trust anything that comes back from the client. Set limits, for example, on what html tags are allowed in user input and don’t be surprised when users try to inject malicious javascript.
• Don’t give in to tantrums
  • This one works for developers without any translation.
• Begin to use time-out and taking away privileges
  • See “set limits” above. Don’t enable client-side javascript any privileges it should not have – treat all client input as suspect. Error on the side of limiting functionality until you are sure it can be done securely.
• Provide your toddler with a safe environment that is well childproofed
  • Make sure you have a development sandbox that lets you experiment with new functionality without impacting mainline production code.

Here’s hoping that Ajax gets through the terrible twos more quickly than the average toddler.

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.)

Basically, you install the plug-in in your copy of IE, and sign in to the Weezu servers. Then, while you browse the web, Weezu “watches” what urls you are visiting, and informs you when other Weezu users are looking at the same pages.

In other words, you can see which other Weezu users (those who also installed the plug-in and created a Weezu account) are viewing the same page you are.

In Weezu’s terms (are they using Google Babelfish for the English version?):

Thanks to the Weezu bar, you can see the avatars of all weezunauts who are connected on the same site as you are, and with a single click start to share messages with them. To achieve this, you only need to install the Weezu bar. Once connected on Internet, you will see the avatars of weezunauts visiting the web sites. Weezu works on all web sites around the world and maybe further…

One of the issues I had with Weezu is the design.

I suppose one could argue design is subjective, but who exactly is the target market for a service which looks like this?:

This is what the Weezu plug-in looks like when it is open – here there is only the user’s avatar because no other weezunauts are visiting the same page at the same time.

Why is the user’s avatar inside the mouth of a giant blue sea monster, hovering near the sea floor in some kind of spongebob squarepants alternate universe? I assume that’s the “Weezuscaphe.”

If you should happen to find another weezunaut, you’ll have the opportunity for a chat:

(I should mention these images are drawn from the Weezu “use” page – I did install and try it out but I never managed to find anyone on the same page as me at the same time).

Other weezunauts’ avatars appear at the left, and by clicking on them you can send them messages.

Why? That’s not entirely clear. Perhaps you want to talk to strangers about the web pages you’re both looking at?

Reminds me a bit of ThirdVoice, which allowed users to leave comments “on” web pages that other Third Voice users would be able to see – except with a synchronous twist, in that the users are there now, or something close to it.

The second issue I had with Weezu is that it’s an IE only experience at this point – though they are working on a firefox version.

Finally, they’ll have an interesting challenge managing the growth of their community.

When it is too small, as it is now, you can’t find any other avatars – you’re just crawling along the bottom of the sea floor all by your lonesome, ” . . . a pair of ragged claws / Scuttling across the floors of silent seas.”

When it gets too big, if it were to catch on among some niche set of users for example, the interface would be overwhelmed by users – at which point it becomes clear that this is just a chat room circa 1996, and plain old IRC might be more effective. It will quickly become “so crowded nobody goes there anymore.”

(OK, did I just manage to quote T.S. Eliot and Yogi Berra in one blog post?)

It might get interesting if, for example, I could set up friend lists – and determine who I might want to chat with if they happened upon the same page. Or, if sites endorsed use of such a plug-in, and made the experience of chatting somehow related to the experience of the site.

Another similar startup in invite-only mode, is Me.dium, which “reveals the hidden world of people and activity behind your browser.” According to Ajaxian, Me.dium offers some similar functionality: “You can see your friends browsing, all with relevance letting you know who is doing similar things, and letting you chat with those people.” I’ve just installed that one, will blog more about it once I’ve tried it out.

• The architecture of participation, and the increased user expectations it is driving,
• The rich interfaces provided by Ajax and related technologies,
• The composition of applications from services, whether as full-blown SOA or simple Mashup

These three major trends fit together very well with Optaros’ overall mission of helping enterprises  meet business needs by leveraging open source software and an assembly-based methodology.

Recently a few very good presentations / articles have appeared that should help make this easier for me to explain and for all of us to understand.

Rise of the Participation Culture

The first is a report, from Steve Borsch and the folks at Connecting the Dots, called Rise of the Participation Culture. It’s available in an html version for reading online as well as in a PDF format (5.9MB) for printing or reading offline, under a creative commons attribution license.

There’s nothing radical or revolutionary about the content it presents, but it provides a very good high level overview for the uninitiated, while managing to neither oversimplify or bore the initiated. Definitely a good “Participation 101″ with quick coverage of RSS, Microformats, Ajax, Mashups, Wikis, Blogs, REST and Web Services, Syndication and Aggregation, Social Networking, Collaborative Applications, User Contributed Content, etc.

Recognizing Web 2.0

The second is a presentation by Kevin Yank from Site Point on “Recognizing Web 2.0: A Plain English Guide” (The ppt and the audio are both available from that page).

Yank covers some of the same ground as the other report, but in a much more developer oriented, insider fashion – much of his audience is folks who consider themselves developers and technical folks. His basic outline includes:

• Sites as Applications
• Participation and the Wisdom of Crowds
• The Long Tail
• Folksonomy
• Blogging
• Open Data & Services
• Feeds
• Microformats
• APIs
• Mashups

He also shows a number of examples: usual suspects like Google Maps, Zimbra, Wikipedia, Digg, del.icio.us, flickr – as well as some less familiar ones: blogbridge, applefritter, overplot.

Web 2.0 is not just a buzzword

Finally, Kathy Sierra at Creating Passionate Users makes an interesting point about insider language, jargon, and the formation of communities of knowledge in Why Web 2.0 is more than a buzzword.

She draws a distinction between “buzzwords” and “jargon” in the context of people who would like to say that “Web 2.0″ is a meaningless term:

But to say it means nothing (or WORSE–to say it’s just a marketing label) is to mistake jargon (good) for buzzwords (bad). Where buzzwords are used to impress or mislead, jargon is used to communicate more efficiently and interestingly with others who share a similar level of knowledge and skills in a specific area.

In other words, while people do still tend to think of “jargon” as a pejorative term, it is to a very large degree a necessary part of building a community of knowledge around a given subject. Professionals in any given discipline (or, perhaps more to the point, passionate amateurs in any domain) always develop an insider language. Not because they want to be elitist (or not just because they want to be elitist) but because it is a natural outgrowth of a set of shared experiences and knowledge.

In trying to build communities, we should not aim for a kind of least-common-denominator language that avoids all jargon, because that will always run up against the need for more specialized language as the subject’s complexity demands. Or, as Sierra puts it:

Not only should we allow domain-specific jargon or expert-speak, we should be driving it! We should help invent short-cuts and specialized words and phrases to make communication among our most passionate–our experts–even more stimulating and useful.

That’s not to say, of course, that experts inside a given discourse community shouldn’t try, with some percentage of their time, and in appropriate forums, to explain those insider terms to those outside – just that experts can’t do so all the time.

Or maybe I’m just trying to make myself feel better about how difficult it can be to explain concepts like “Web 2.0″ or “Next Generation Internet” to the person next to me on the plane, before their eyes glaze over and they look at me like I’m talking in ones and zeroes. (Whenever I get too deep into tech jargon my wife starts to say “One, Zero, Zero one one. Zero zero. one zero one” until I stop.)