Simple
Ajax
Mashup techniques

Isolation

Ajax applications can reach a wider audience by overcoming facets that make them appear isolated:

1. Users must log into each Ajax application separately.
2. Users must download and upload data to and from each Ajax application. Applications do not inter-connect.
3. Users often copy / paste content from Ajax applications into other documents. Such copies often loose formatting fidelity and look much different than they did in the source document.

These issues and the technical skills required to work around them may slow widespread use. This document recommends standards and techniques to solve these problems. The recommendations make use of proven standards, are easy to adopt, and support some of the most difficult Ajax scenarios.

Please contribute to these recommendations by posting to this forum or contact tomsn@inetoffice.com or eric@sharemethods.com.

1. WebDAV  (Web-based Distributed Authoring and Versioning)

WebDAV is a very well supported standard based upon HTTP for transmitting files & their metadata. Judicial support of WebDAV can solve isolation problem B. WebDAV implementations are available for almost every server type.

Recommendation 1.0:
Ajax applications should support WebDAV both as a server for export and as a client for document import.

Recommendation 1.1:
For Ajax servers that use a 'tags', 'star', or other mechanisms to organize documents, they may, for the purpose of import and export, map such mechanisms to the hierarchical organization HTTP and WebDAV specify.

Recommendation 1.2:
Ajax applications that rely on a database back end should expose commonly used file formats to serve WebDAV requests. For example, an online Database application could provide .csv versions of its tables via WebDAV. Generating such versions can be done just-in-time during the WebDAV request rather than every time a table is modified. Similarly, an online spreadsheet would serve .xls documents generated just-in-time to satisfy WebDAV requests.

2. WebDAV Authentication

To really solve isolation problem B, users will expect our applications to read and write documents with each other without their having to log on repeatedly. To achieve this we propose a standard set of CGI parameters that when associated with an Ajax user session will enable that session to communicate to other WebDAV document stores.

Recommendation 2.0:
Accept, store, and utilize these WebDAV login credentials as CGI parameters to your application's entry point URLS:

Example:

https://supercool.com/coolwrite.jsp?StorageScheme=WebDAV&StorageDomain=storedocs.com
&StorageServerUrl=sv1.storedocs.com/joe&StorageSessionId=DJF789375

Recommendation 2.1:
Use the 'Basic' HTTP authentication scheme over SSL (https:). This simplifies the server's management of WebDAV passwords and is secure. Many WebDAV servers cannot use 'Digest' authentication because they don't have access to the user's password in plain text or a compatible format.

Recommendation 2.2:
WebDAV servers should support authentication via a Session ID as well as the user's password. The Session ID is allocated by the WebDAV server and has a limited lifetime. We don't wish to pass actual passwords among applications. By so doing, the WebDAV server can launch 3rd party Ajax Applications, pass them the CGI parameters listed in Recommendation 2.0, and the 3rd party application can read and write directly to the user's primary documents without any intervention by the user.

The following scenario is enabled by following recommendations 1.0 - 2.2. A user logs onto their HOME Ajax application and begins work. During the session he browses files, templates, and application links. He clicks a file, template, or application link and launches the 3rd party application of his choice. There he begins editing the clicked on document. When finished, he clicks save and saves the document back to his HOME Ajax application's document store.

3. Single Sign On

Given that recommendations 2.* provide a mechanism for a 3rd party Ajax application to authenticate via WebDAV against a user's HOME Ajax application, this authentication can also be used to federate the HOME Ajax application's user identity to the 3rd party Ajax application.

This is useful if the 3rd party Ajax application offers services and storage beyond simply reading, editing, and writing the WebDAV served document. In this case the 3rd party Ajax application would provision a local account for the user. The account would be uniquely identified by the CGI parameters of Recommendation 2.0 and authentication into this account would always be done by authenticating back to the user's HOME Ajax Application's WebDAV server. No sign up process or new password would be needed.

This mechanism does not immediately accommodate document sharing policies or roles and permissions assigned to 3rd party Ajax application accounts. Once a user has tried the 3rd party Ajax application and wishes to make regular use of it in a collaborative environment, their federated-to 3rd party Ajax application account can be converted to a traditional, full featured account there.

A better solution, when possible, is to:

Recommendation 3.0:
Support identity federation via the Liberty Alliance standards.

4. WebDAV Opaque and Interpreted Metadata

One of the big advantages of WebDAV is its support for Metadata associated with a file. Since we are round-tripping WebDAV requests from a HOME server, to a 3rd party application, and back to the HOME server, we wish to support the transmission of Metadata as well.

Recommendation 4.0:
Accept as a CGI parameter and transmit back to a document's WebDAV server opaque XML blocks of Metadata. The CGI parameter is:

Recommendation 4.1:
Provide UI for a user to supplement the PROPPATCH <xml> Metadata supplied in the StoragePROPPATCH value associated with a file. For example, provide entry fields for Title, Keywords, Description, or other purpose specific values.

Recommendation 4.2:
As well as providing the opaque StoragePROPPATCH Metadata to a 3rd party Ajax application, provide the following meaningful values via CGI parameters. Such values give a document create or edit launch context and make it much easier to craft fully automatic, easy to use solutions using SAC.

5. File Import, Attach, Upload, and Retrieve

Ajax applications currently support browser file uploads to import into their repository or to attach documents to other objects (e.g. mail messages). Supporting only uploads from the local hard drive makes it difficult to use more than one application in any scenario.

Recommendation 5.0:
In all places that your application supports Upload File, also present a 2nd option called Retrieve File. Accept arbitrary URLs in the Retrieve File field and process them as follows:

1. If the URL specifies a publicly accessible HTTP location, then retrieve the file via HTTP GET.
2. If the URL specifies a WebDAV location for which you have login credentials via CGI parameters (Recommendation 2.0), then use those parameters to do a WebDAV GET.
3. OPTIONAL: If the URL specifies a WebDAV location for which you don't have login credentials, prompt for them. If the URL specifies an FTP or other protocol location, attempt to retrieve from that location.

Note that:

In both Firefox and IE, you can click and grab a page's icon at the left of the address field (favicon.ico or an 'e' in IE and a blank page icon in FireFox) and drag it to an edit field. This fills the URL into the edit field. This is an easy way for user's to find and view a document, and then copy it's URL into the Retrieve field in another application.

6. Document HTML Portability

Ajax applications often support exporting documents, data, or screens as HTML. This enables users to publish, share, and email the results of their hard work to others.

The HTML generated by an Ajax application can, however, be difficult to import or combine with other documents. Using CSS styles (i.e. classes), JavaScript, or any external linked element can make the document look or perform poorly when pasted into another document or imported into another application's environment. The following recommendations ensure that the HTML your application generates looks its best in all scenarios.

Recommendation 6.0
Use inline style="..." CSS formatting on all tags in user's HTML documents. Minimize the use of class=. This enables the user to select, copy, and paste content to other documents while maintaining the precise formatting of the content.

Recommendation 6.1:
Do not place JavaScript within user's HTML documents. JavaScript often gives errors when portions of a document are copied and pasted to another document and may error when an entire document is transmitted to another environment.

Recommendation 6.2:
Provide an option to export documents in MHTML (Mime HTML, *.mht) format. This format encapsulates the images and other external components within a single file. It is the same format that email programs use to send HTML rich text messages. Supporting this format solves a great number of problems related to moving files among accounts and among systems. See also http://www.dsv.su.se/~jpalme/ietf/mhtml.html.

Recommendation 6.3:
Support the Zimbra ALE standard for embedding and linking documents. ALE supports the ability to embed one type of document within the contents of another. For example, you can embed a spreadsheet within a word processor document. When clicked on, the spreadsheet application becomes live and you can edit your spreadsheet as a spreadsheet.

This contrasts with Recommendations 6.0 - 6.2 which apply to static copies of a document being copied into another document and edited with the receiving document's tools. Both scenarios are useful. Desktop applications typically identify the paste type as Paste Special ... text, or Paste Special ... object.

Conclusion

Challenges remain to make Ajax applications as powerful and easy to use as desktop applications. On the desktop, the operating system provides a wide range of services which applications use to interoperate and which users rely on to organize their work.

On the Internet, protocols and standards replace the APIs of a desktop operating system. Over time, a small set of standards will emerge dominant and every online application will support them. At that point every online application will interoperate with every other in a richer, easier, more powerful manner than their desktop brethren do today.

In the final analysis, it won't matter so much which set of standards became widespread, but only that some do become widely supported. We request that you imagine the possibilities, submit your ideas to the forum hosting this document, and champion the support of additional standards within your Ajax application.