http://qs1969.pair.com?node_id=350455

I use a Perl based development framework called XML::Comma for the majority of my web-based application programming. Recently folks from the Comma community have been musing about how to launch and interact with desktop applications from a website built on top of Comma.

The following meditation is an attempt to summarize the recent discussions and bring them to a larger community for scrutiny. I should give fiar warning that the meditation is off topic. The Comma framework is written almost entirely in Perl, but the meditation focuses almost entirely on interacting with desktop applications from a site built on top of Comma.

XML::Comma Conversant Desktop Applications Over HTTP [1]

1. The problem

We've all reached the point with a particular application where we've hit the virtual wall of a browser's capabilities. Sometimes it happens when a client wants WYSIWYG HTML editing in a web based CMS/Blog/Wiki. Sometimes it's worth the political capitol and training that it takes to either convince that client they are wrong or train them to use markup. Sometimes it's not.

The most cross-platform likely-to-be-supported-in-the-long-run browser based solution to this (and similar "browser as an application" ) problem(s) has been to write a tangle of JavaScript and then pray that the maintainer doesn't find your address.

If the client is running a decent HTML editor it probably has some built in publishing capabilities. These come with their own set of problems. First, they probably only publish via FTP or webDAV. If we're lucky enough to get some script-ability out of them it's probably going to be either JBHSL (Joe Bob's Homegrown Scripting Language) or "real" language that a small, specialized subset of the programming talent that one has available for project work is comfortable slinging code to.

2. The players

Quite a few players have implemented their solution to the problem of making the browser feel more like a desktop application (or how to control desktop applications from a browser). JavaScript, ActiveX, XUL, Java or Java + WebStart (as well as many others) have all tried to solve the problem and succeeded and failed to varying degrees and in different ways. Some (such as XUL) are fairly young and are still making progress. Others (such as ActiveX) have settled into their niche market (integrating productivity tools to network secured intranets running atop of some breed of Microsoft Windows).

Miguel de Icaza has seemingly done some thought [2] on the topic. Aside from the fact that I think that he over-estimates Microsoft's ability to deploy a secure product, I think he makes some excellent points, not least of which is the fact that folks are going to latch on to running integrated desktop applications that are conversant over HTTP. We already have in some small ways (I'm always a little miffed when I rip a CD from a place where I can't connect to CDDB).

3. Proposed solution

The desktop applications that have succeeded in "integrating" with todays internet are mostly small, special purpose, stateless applications. When I listen to an MP3 stream, I don't want my browser to act like an MP3 player, I want my slick, skinned XMMS to launch and play the stream.

In his "Planning for the Future" paragraphs Mr. Icaza sees one possible solution as coming "up with our own, competitive stack".

The following is how Kwindla Kramer imagined we could use HTTP and some header munging to solve the problem of providing rich content editing tools that talk to Comma:


      -- The Protocol --

      1) Server -> (browser) -> Helper App

      Assumptions: an initial request is made by clicking on the
      "edit this on your desktop" link in a web browser. The
      HTTP Response is read by the browser, and because it has
      a special Content-Type, is dispatched to a user-defined
      helper application.

      The Content-Type header:

        Content-Type: application/x-comma-edit

      The body of the Response is itself constructed like an email
      or HTTP utterance, one or more header lines, then a blank
      line, then a body.

      The required Comma-Edit header:

        PostLocation: <url>

      Other Comma-Edit headers may be defined to extend the
      protocol, for example:

        ServerState: <server defined> StyleSheet:
        http://foo.com/styles.css AllowedStyleClasses: headline,
        boldname, small-blockquote LayoutWidth: 240px

      The body of the Comma-Edit response is the text to be edited.

        2) Helper App -> Server

      An HTTP POST Request to the PostLocation specified by the
      server, with one special header:

        Content-Type: application/x-comma-edit.post

      Apps may add any headers they want to the Request, but they
      *must* also follow a general rule:

        The helper app takes any Comma-Edit headers that it does
        not have explicit rules for dealing with and turns them
        into HTTP headers by prepending "X-Comma-Edit-" onto the
        header name and preserving the header value unchanged.

      For example:

        X-Comma-Edit-PostLocation: <repeat PostLocation header>
        X-Comma-Edit-ServerState: <repeat what the server sent>

      The body of the request is the (possibly) changed text.

       3) Server -> Helper App

      An HTTP Response detailing success or failure.

  

This makes a whole bunch of sense to me. If I were developing this particular application I could use Java + Swing, wxWidgets (via Perl, Python or C++), Tk, QT, GTK, .NET or anything else that has some access to native "widgets". As cool as I think XUL or Visual Basic + ActiveX controls are, I don't want to be tied (or want to tie my fellow programmers) to that specific of an implementation.

The HTTP header munging way seems to solve the problem at hand flexibly enough for the programmer and robustly enough for the client.

Does this make sense?

  -- Douglas Hunter

This document was also posted to the comma@xml-comma.org mailing list, where the discussion is ongoing.

Originally posted here.

[1] Most of the meat of this document was shamelessly borrowed from an off-list conversation between Kwindla Kramer and Guido Sohne. Thanks fellas.

[2] http://primates.ximian.com/~miguel/archive/2004/Apr-24.html