|go ahead... be a heretic|
[OT] Desktop applications over HTTPby dug (Chaplain)
|on May 04, 2004 at 17:49 UTC||Need Help??|
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. 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.
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
Miguel de Icaza has seemingly done some thought  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 email@example.com mailing list, where the discussion is ongoing.
Originally posted here.