[prog] Using HTTP to interact with desktop applications

[Douglas Hunter]

Meredydd wrote:
> On Tuesday 04 May 2004 23:29, Douglas Hunter wrote:
> 
>>   http://people.plusthree.com/~dug/edit_over_http.html
> 
> The first thing that my mind jumps to is "great, but not 
> backwards-compatible" - and, unfortunately, I can't really see a 
> suggestion, however brilliant, to sway (for example) the behemoth that 
> is the IE development team. So, one thing I think it really needs is 
> backward-compatibility - some way of falling back to the aforementioned 
> horrible hacks / HTML forms rather than WYSIWYG / existing methods for 
> launching applets or ActiveX. If you want it to be accepted by users, 
> unfortunately, it can't really be an "If your browser supports blah, 
> click here, else click here. 

That's an excellent point.  When we were initially thinking about this 
that's something that we tried to keep in mind.  We didn't want a new 
protocol (hence pushing things over HTTP).

We're leaning towards settling on the Content-Type header because that's 
what most other folks seem to do to launch an external application.

The first thing which pops into my head is
> sending a normal page (to launch the HTML form / ActiveX control / 
> whatever, or at least to redirect to a page which will), with some 
> custom headers, plus one more - a URL from which to actually get the 
> content. That way, a browser which just ignores your headers would 
> still present a seamless (if somewhat basic) user interface to the 
> client, and one with extensions installed would do the funky stuff.
> 
> Unfortunately, you use content-type too, which is, I suppose, the 
> sensible way of going about the task, but would blow the above approach 
> out of the water. I'm sure you could come up with something better, 
> though...
> 

I may not be parsing what you are saying properly (still on my first cup 
of coffee {grin}).  It's also possible that I did a bad job of 
explaining what I had in mind.  I was imagining an interaction something 
like this:

1) user installs desktop application that knows how to interperet the 
X-Comma-Edit headers (these are just X-Headers that every one else would 
ignore).

2) user clicks "Edit on my desktop link" from a piece of content on a 
website.

3) server sends "Content-Type : application/x-comma-edit" header which 
launches the desktop application

4) user edits content and clicks "save" (or something).

5) desktop application POSTs back to the URI sent in the X-Comma-Edit 
header.

6) server processes the POST and sends a response code back.


If a user didn't want to edit on their desktop, they could just click 
the regular edit link which would send "Content-Type: text/html" and be 
displayed by the browser (possibly with some JavaScript or something to 
make it easier on them).

As I think about this a little bit more, when the user installs the 
desktop application, we might ask them to authenicate to the server and 
add the "I have desktop editing capabilities" flag to their profile (if 
they wanted to).  Then we could display the "Edit on my desktop" link 
only to folks who had asked for it.

I hope I didn't just muddy the waters, and thanks a bunch for your response.

> Meredydd

   -- Douglas