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