Content Editing Nirvana

Content Editing Nirvana

I was chatting to <shameless-name-drop>Brian Behlendorf</shameless-name-drop> about the integration between Microsoft's Sharepoint, IE and Word 2003. It seemed neat, I said, that Internet Explorer can load up Microsoft Word for the editing of docs (.docs in this case) on a website, and share its authenicated/secure context/session/connection. He managed to reflexly provide a solution to the Open Standard equivalent that I'd been struggling to design for a while.  First some context..

Mozilla/Suite and content management

Mozilla/suite (may it rest in peace) had an ability to load up Composer when the user pressed Ctrl-E (edit) on a web page. You'd be editing the page in-situ. If you did a Ctrl-P (publish) it would go back (assuming the server in question supported that operation, and you had name/password for it).   This was limited to HTML of course, but it worked well.  Two years ago we (ThoughtWorks) tried to launch an intranet portal application leveraging Subversion, and Sitemesh (see http://svn.haxx.se/dev/archive-2003-03/0966.shtml). It was ill-concieved for a couple of  reasons. Some to do with SecurID, one to do with Subversion not leveraging Apache's associations for incoming files. e.g. Foo.html was being loaded into Subversion as text/plain if pushed up by Mozilla/Composer.

Ubiquitous application interoperation

Mozilla have a browser and composer in the same executable makes for eash context/session/connection sharing for view-becomes-edit operation needed for this type of content editing.  Having a different executable (possibly written in some other language) for the edit mode makes for an interesting problem for how the two would communicate.  They could share a temporary file. The browser would simply invoke the following to initiate editing..

  c:\program files\MyCoolEditor.exe c:\temp\SomeLongContrivedAndObscureFileName.doc

.. but that is fairly poor in terms of security. Temporary files suck. It also does not allow much interoperation between the browser and the editor after instantiation. For example, the browser may way to ask the editor to abandon its edit (the user has left the page). The editor may want to veto the request (unsaved edits).   You can't do that via temporary files.

CORBA and XPCOM

My thinking was that the browser and the editor had to implement a standard RPC or IPC. The browser would then hand an object to the applicable editor.  Something function like editor.edit(webFile);

Anyway that sucked, because you'd have to ensure that each launguage on each operating system has easy to use implementations of the RPC technology in question.  CORBA is far from transparent in use, and XPCOM never got the cross platform success that perhaps it should have done.  AppleScript and Visual Basic for applications are non runners of course as they are particular desktops and not cross platform. Nor are they open source or standard.

WebDAV

The simple answer, provided by Brian was WebDAV.  The browser should also be a web server (for localhost only) on some obscure port.  It would hand off editing instructions to associated or configured applications by command line as usual ..

  c:\program files\MyCoolEditor.exe http://localhost:7654/SomeLongContrivedAndObscureFileName.doc (windows)
  /Applications/MyCoolEditor.app http://localhost:7654/SomeLongContrivedAndObscureFileName.doc (mac)

That contrived file is specifically for the one editing event, and not reused. It is also subtly linked to the original web server, whatever the obscure authentication mechanism or nature of the secure connection, proxy, firewall etc.

Entry Level

It would be fairly easy for the browser to implement a socket server that could serve content over HTTP. Accepting back the changed content (possibly more than once) would be the bit that the WebDAV aspect would deliver. As an entry level that would work great. All that a compatible application would need to be able to do was read files over HTTP and publish them back in the thinnest subset of WebDAV (that's what Mozilla/Composer did). 

Advanced

The next level of compatibility for compatible editing applications would be one that implemented some form of command set for interop. Something over HTTP is the ideal with XML-RPC being a front runner (it is more ubiquitous than SOAP). With that, the editor could register for with the browser for tighter interoperation.  It could be that there is some yet-to-be-invented WebDAV/RPC, but until that moment XML-RPC looks good :

1) Browser invokes c:\program files\MyCoolEditor.exe http://localhost:7654/SomeLongContrivedAndObscureFileName.doc
2) MyCoolEditor GETs http://localhost:7654/SomeLongContrivedAndObscureFileName.doc
3) MyCoolEditor, via XML-RPC GETs http://localhost:7654/SomeLongContrivedAndObscureFileName.doc.register&param&param&etc

Changes needed

• W3C standardises the localhost HTTP server mechanism by which browser speaks to an associated editor or other application.
• Safari, Mozilla, Firefox, Konqueror, Galeon, Camino, Opera, OmniWeb, InternetExplorer all change to support the new standard
• Greg Stein or the Collabnet developers (Brian Fitzpatrick, Karl Fogel, Mike Pilato) refactor mod_dav into a couple of bits allowing browser committers to utilize the core to deliver DAV serving capaility to their browser.
• Client application authors get familar with libwww

Incidentally, it appears that NVU is picking up the development of Composer. I sure hope the WebDAV support is beefed up after it goes 1.0.