Congratulations to Aptana (Kevin Hakman), Dojo Foundation (Kris Zyp), Eclipse Foundation (Mike Milinkovich) and IBM (David Boloker), who have been elected for two-year terms on the OpenAjax Alliance Steering Committee. We look forward to their strong leadership and guidance. They join Microsoft (Bertrand Le Roy), Nexaweb (Coach Wei) and TIBCO (Howard Weingram) on the Steering Committee.

OpenAjax Alliance is pleased to announce it will be a media sponsor of The Ajax Experience in Boston. Ajaxian.com is offering the OpenAjax community members a special rate for attending The Ajax Experience, September 29 - October 1. Register with the code ‘openajax’ to save $100 off the registration fee, making the price only $1395 after (regular rate: $1495). If you are interested in coming with a team, contact Tracey West at twest@techtarget.com. Groups of 3 or more are being offered an extra $300 off per person. Register for TAE here.

The members of the OpenAjax Alliance will hold a one-day face-to-face meeting on Thursday, Oct. 23, 2008, the day after AJAXWorld RIA Conference and Expo 2008 West. The face-to-face will be hosted by Microsoft and located at a TBD location in Silicon Valley in the San Francisco Bay Area.

One key agenda item will be to review the results from the 2008 InteropFest (also, see [blog post]) and discuss what changes are needed to OpenAjax Hub 1.1 and OpenAjax Metadata based on those results.

OpenAjax Alliance is pleased to announce the start of this year’s interoperability event, the 2008 InteropFest for IDEs and Mashups. The 2008 InteropFest continues until just before AJAXWorld West 2008 (i.e., until just before October 20, 2008).

The 2008 InteropFest focuses on two main areas: Ajax IDEs and secure mashups.

InteropFest Focus #1: Ajax IDEs

Today, Ajax tooling falls short of potential, in large part due to interoperability problems. There are a number of Ajax IDEs today and hundreds of Ajax libraries, but only a small fraction of IDEs work well with only a small fraction of Ajax libraries, usually due to one-off coordination between particular Ajax libraries and particular IDEs.

To promote strong plug-and-play between Ajax IDEs and Ajax libraries, OpenAjax Alliance has developed an industry standard called “OpenAjax Metadata” (http://www.openajax.org/member/wiki/OpenAjax_Metadata_Specification), which defines an industry standard XML grammar for the following:

• JavaScript APIs - Descriptive information about the namespaces, classes, methods, parameters, properties, etc. found in JavaScript libraries. This API metadata can be used by Ajax IDEs to deliver content-assist features and interactive help.
• Widgets - XML metadata, along with wrapper HTML and JavaScript, for the UI controls found in many Ajax libraries. This widget metadata can be used by Ajax IDEs to populate widget palettes and to allow visual layout of Ajax applications.

InteropFest Focus #2: Secure Mashups

OpenAjax Alliance is working on multiple related technology efforts in order to help realize the potential of mashup technologies to enable user-generated situational applications, where applications are assembled by end users by dragging various widgets onto a canvas and connecting widgets together. The two main inhibitors to widespread deployment of mashups are security issues and interoperability challenges:

• Mashup security: OpenAjax Alliance is addressing security primarily through the secure mashup runtime environment found within OpenAjax Hub 1.1.
• Widget interoperability: The alliance is addressing widget interoperability primarily through its widget metadata standards found within OpenAjax Metadata (see the related discussion of widgets in the discussion about IDEs)

The OpenAjax Hub 1.1 is the key technology piece for addessing mashup security issues. OpenAjax Metadata for Widgets is the key technology piece for addressing the widget interoperability challenges.

Further information

The 2008 InteropFest is a major interoperability event covering multiple workflows, multiple types of products, multiple technical specifications, and multiple open source efforts. For more information, see:

• The supplemental blog page on the 2008 InteropFest
• Main wiki page on the 2008 InteropFest
• Reference Implementation of a Sample Mashup Application that uses OpenAjax Hub 1.1 and supports OpenAjax Metadata

The Ajax community ranks vector graphics as top request

OpenAjax Alliance has produced a summary report of its browser wishlist initiative at:

• http://www.openajax.org/runtime/wiki/Summary_Report

By July 13, when the voting closed, this initiative has turned out to be a bigger success than expected. Given the amount of effort required to read and understand the vast web technology landscape, and the relatively limited time and resources available to the OpenAjax Alliance Runtime participants, we were hoping for 50 or so people to vote, which would be meaningful to establish a rough idea of what’s most important to the community.

Voting results are available at:

• http://www.openajax.org/runtime/wiki/Feature_Requests_Summary_Page
• http://www.openajax.org/runtime/wiki/Phase_II_Voting_Summary
• http://www.openajax.org/runtime/wiki/Phase_II_Voting_Details

Here are some quick statistics:

• 222 people participants
• 143 people voted
• 55 feature request being written up
• Various industry leaders contributed
• A discussion thread spawns on Slashdot with 628 comments (http://tech.slashdot.org/article.pl? sid=08/06/30/1845201)

Among all the feature requests, 2D Drawing/Vector Graphics is clearly the most desired feature by the community. It received most votes (110 people voted for it), and highest total score (842, over 10% higher than the second feature request). The second top feature request is enhanced security for cross-site scripts. The third and fourth were better APIs for scripting and styling and HTML DOM performance. Here are the top 10 features:

• 2D Drawing/Vector Graphics
• Better Security for Cross-site Scripts
• Better APIs about positioning and styling
• HTML DOM Operation Performance In General
• Better Support for Rich Text Editing
• The Two HTTP Connection Limit Issue
• Better UI Layout Support
• Native JSON Parsing
• Persistent Connections Issue
• Video and Audio

Here is what pops out from the voting:

• Graphics - The top vote getter was 2D Drawing/Vector Graphics. Ajax developers today are achieving astoundingly rich graphics effects through clever techniques leveraging JavaScript, CSS, images, and whatever vector graphics features they can find (usually, SVG, VML and Canvas), but browser differences are a major pain point among Ajax developers. Mozilla, WebKit and Opera support both Canvas and SVG with good interoperability (although Mozilla does not yet support SVG animations). IE is the holdout. The call-to-action is for all browsers, particularly IE, to support both of the industry standards for 2D vector graphics, SVG (the DOM-based standard) and Canvas (the procedural-based standard).
• Security - Web security is an important topic for leading Ajax developers. The second top vote getter was Better Security for Cross-Site Scripts (XSS), but other security requests also receiving high votes, such as Strong Cross-Site Request Forgery Protection (which it turns out was the 11th top voter-getter). The perception of the moderators is that it’s not just XSS, but that the community cares about all aspects of ensuring that the Web is secure, and in fact more secure than it is today. Recently, Mozilla has authored a proposal that might help make the Web more secure: http://people.mozilla.com/~bsterne/site-security-policy/. Note that Native JSON Parsing can be considered a security feature because without it Web developers are more inclined to use JavaScript eval() to process JSON data, which might allow for XSS attacks.
• Better low-level CSS and DOM support for layout - Two of the top vote-getters were Better APIs for positioning and styling and Better UI Layout Support. These requests come from the widget developers within Ajax toolkit projects who design Ajax-based UI controls by taking advantage of what the browser gives them, such as DOM, CSS, images, and table layout. They often run into walls, and their jobs could be much easier (and performance much faster) if the browser included a small number of additional (relatively small) features, such as stretchable layout (e.g., flexbox in XUL) and the ability to determine the location and size of objects (and containers) within the page.
• Performance - The top vote-getter in the performance area was HTML DOM Performance in General. In discussions over the past year with leading Ajax developers, the moderators believe that the Ajax community wants performance improvements in all aspects of the browser runtime, including DOM, JavaScript, and rendering, but DOM performance was singled out by the community because Ajax toolkit developers have found that DOM access is the top performance barrier today. The key high-level message is keep making the browsers faster, but even blazingly fast JavaScript isn’t going to help if making DOM calls is too slow.
• Rich text editing - Various people in the Ajax community want to move desktop-like document editing into the browser. However, the contributors to this feature request did not outline a detailed strategy for how to accomplish this in future browser. The takeaway is that the Ajax community wants Better Support for Rich Text Editing , and hopefully one of the browser teams will push the envelope in this direction and send standards proposals so that the other browsers can also provide this functionality.
• Comet (server push) - Two of the top vote-getters were The Two HTTP Connection Limit Issue and Persistent Connections Issue. The underlying requirement is that many Ajax applications, such as dashboards, require an efficient and robust mechanism for having the server send data to the client on an event-driven basis. Today, server push in Ajax is often accomplished using “Comet” techniques such as long-lived HTTP connections, but the Ajax community would prefer if server push was a native browser feature.
• Video and Audio - Video and Audio also receiving strong support, coming in as the 10th-most requested feature.

The next step is to communicate with browser vendors. We have had calls with some of the browser vendors such as Microsoft IE team during Phase I. OpenAjax Alliance will try to get in touch (or continue) the dialog with browser vendors to convey what the community is looking for.ser vendors to convey what the community is looking for.

We are pleased to announce that one of the leading mobile phone makers, Sony Ericsson, has joined OpenAjax Alliance and will participate in our Mobile Ajax activities. We look forward to their help in advancing Ajax technologies on mobile devices.

The OpenAjax Alliance is developing an Ajax industry wishlist for future browsers, using a dedicated wiki. The feature list now lists 37 separate feature requests, covering a wide range of technology areas, such as security, Comet, multimedia, CSS, interactivity, and performance. The goal is to inform the browser vendors about what the Ajax developer community feels are most important for the next round of browsers (i.e., FF4, IE9, Safari4, and Opera10) and to provide supplemental details relative to the feature requests.

The initiative is now in its final voting phase, and the alliance is issuing a call-to-action to Ajax developers to vote on which features should have the highest priority. To make the voting process as quick and painless as possible, the voting page lists all 37 feature requests, along with a popup menu for each feature with possible values of 0 (no importance) to 10 (highest importance). The voting period ends on July 10, 2008. To vote, you will need a wiki login (as explained on the wiki home page) and then cast your votes on the Phase II Voting wiki page. The alliance also strongly encourages people to comment on the wiki pages for each of the existing features and to add any important new features that are not yet on the list.

The initiative is open to both OpenAjax Alliance members and to non-members. The alliance especially would like participation from Ajax toolkit developers and leading web developers with expertise in using open browser technologies to achieve rich user experiences. The initiative operates on an honor-system basis.

The Mobile Task Force at OpenAjax Alliance has completed its fast-track exploratory phase into Mobile Device APIs.

What we mean by the term “Mobile Device APIs” are JavaScript APIs available within the browser engine to allow HTML+JavaScript applications to access device-resident capabilities such as current location, the phone dialer, the address book, the SMS system, the MMS system, the local email system, battery levels, network connection status, and various other things such that the next generation of Mobile Ajax applications can be delivered to the community, but in the context of appropriate security measures. Our effort looked at 4 scenarios: running in the browser, running as a widget, running within a compiled application, and site-specific browser applications.

The OpenAjax Mobile Task Force decided in February to pursue a fast-track exploratory phase where the time period was fixed (i.e., finish by the end of April, 2008) and we would try to get as far as possible in assembling use cases, requirements, and characterizing security considerations. The main purpose of the exploratory phase was to get a broadbrush characterization so that the members of OpenAjax Alliance could make decisions in the May/June timeframe about what formal activities at OpenAjax Alliance might help move the industry forward.

The exploratory phase met (and probably exceeded) our objectives. As we had hoped, we assembled a good set of use cases and requirements and outlined a conceptual framework around security considerations. Many thanks to the participants, which included contributions from Aplix, Cisco, IBM, Ikivo, MobileAware, Motricity, Mozilla, Oracle, and Vodafone. (Sorry about any omissions.)

Now it is May/June, and we have indeed decided on our next step, which is to launch on open source project. I will blog about that later.

(Note: One more apology. This post should have gone out about a month ago when the exploratory phase actually finished.)

The OpenAjax Alliance has recently published two new white papers, one on Mobile Ajax and one on recent browser advances.

The first white paper, Introduction to Mobile Ajax for Developers, provides an overview of Ajax application development for mobile devices. The white paper was the collaborative effort among several leading companies in the mobile industry within the OpenAjax Alliance’s Mobile Task Force. The target audience for the white paper is both the Ajax desktop developer who wants to also support mobile phones and the existing mobile developer who is interested in moving towards Ajax for future application development. The white paper characterizes the state of Mobile Ajax today, identifies the key challenges, and highlights the unique opportunities for innovative new applications offered by today’s mobile devices (e.g., telephony, location, camera, SMS). The white paper provides a comprehensive list of developer tips for addessing the challenges and taking advantage of the opportunities.

The second white paper, Good News for Ajax - The Browser Wars Are Back, highlights the major changes in the browser world that are manifesting themselves in this year’s browser releases (i.e., IE8, Firefox3, Safari 3.1, Opera 9.x). The white paper describes how the Open Web, after years of slow advancement, is now adding key features at a rapid rate. The white paper highlights the importance of the new Mobile Web, where desktop Web browser software is appearing on mobile platforms from leading mobile vendors, with shipping products or announcements already from Apple, Google (Android), Microsoft, and Nokia. The long-term result of today’s healthy, fast-paced competition among the browser vendors will be better cross-browser interoperability, improved performance, and major new opportunities to developers for innovation.

The OpenAjax Alliance is requesting industry feedback on two companion initiatives, OpenAjax Conformance and the OpenAjax Registry, which have been under development for the past year.

The term OpenAjax Conformance is shorthand for the set of conformance requirements that OpenAjax Alliance places on Ajax technologies, products, and applications to promote interoperability. Version 1 of OpenAjax Conformance defines 10 specific conformance requirements on Ajax runtime libraries. An Ajax runtime library that meets these conformance requirements will allow Web developers to use that library conveniently within a given Web page with other OpenAjax Conformant libraries.

OpenAjax Conformance provides the following benefits to IT managers and the Ajax developer community:

• Seamless integration of multiple Ajax products and technologies within the same Web application, particularly with applications that use mashup techniques
• Greater certainty about product choices, where OpenAjax Conformance plays a similar role in the Ajax community as the Good Housekeeping Seal does with consumer products
• Lower training costs, lower development costs, and faster delivery of Web 2.0 innovations due to industry adoption of common approaches that build from OpenAjax standards
• Interchangeability of OpenAjax Conformant products, such that customers can choose among multiple vendors (and change vendors in the future)

OpenAjax Conformance defines three conformance levels. Full Conformance is for Ajax products that have sufficiently strong Ajax interoperability characteristics that there is high expectation that the given product can be used successfully and conveniently with other Ajax products as part of the same Ajax development task. Configurable Conformance is for Ajax products that support all of the same strong interoperability characteristics as for Full Conformance, except not in their default configuration. Limited Conformance is for products that meet a particular subset of the conformance criteria, and therefore have taken important steps towards Ajax industry interoperability, but on the question of whether the given Ajax product can interoperate successfully and conveniently with other Ajax products, the answer is “it depends”.

The OpenAjax Registry is a centralized, industry-wide Ajax registration authority managed by the Interoperability Working Group at OpenAjax Alliance. The Registry maintains an industry-wide list of Ajax runtime libraries and various characteristics of each library. For each library, the Registry lists:

• JavaScript globals
• runtime extensions (both JavaScript and DOM)
• markup extensions (e.g., custom elements, attributes or CSS class names)

These two technologies have now entered a public review phase that ends on June 30, 2008. Feedback can come in various forms, such as email to public@openajax.org, or comments posted on various industry blogs. After the public review phase ends, the members of OpenAjax Alliance will adjust the two specifications to take the feedback into account and then move the two specifications towards version 1.0 completion and approval.