Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

[OT] Desktop applications over HTTP

by dug (Chaplain)
on May 04, 2004 at 17:49 UTC ( #350455=perlmeditation: print w/replies, xml ) 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]

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

Replies are listed 'Best First'.
Re: [OT] Desktop applications over HTTP
by exussum0 (Vicar) on May 04, 2004 at 18:43 UTC
    What does SOAP, XML-RPC and the third (uses simple http post/get with a standard response format) not provide that what you have does provide? These three boast simplicity in readability and/or robustness, while other technologies boast "other" things. RMI for instance, has very tight ties with java, so it's simple to integrate.

    Tight integration with whatever you are doing is a valid reasson

      Thanks for your response.

      What does SOAP, XML-RPC and the third (uses simple http post/get with a standard response format) not provide that what you have does provide?
      Well, SOAP and XML-RPC provide excessive bloat that the solution proposed in the original post doesn't {grin}.

      The "protocol" section of the original post begins to describe how to standardize on which HTTP headers to use in which ways to do "simple http post/get" type interactions.

      -- Douglas Hunter

        says dug:

        The "protocol" section of the original post begins to describe how to standardize on which HTTP headers to use in which ways to do "simple http post/get" type interactions.

        That has already been standardised in WebDAV. If your HTML editors (I'm guessing FrontPage) already support WebDAV, I'd try writing a WebDAV API to your server. Modules like HTTP::DAV or HTTP::Webdav might be of use.

        We've done something similar where I work. We have content production software that runs under mod_perl with a SOAP::Lite interface. SOAP was an attractive options for us since it was relatively quick and painless to set up, and we wrote our own desktop application. We've been using it now for a year and a half.

        Our desktop client application is written using Wx. We use an ActiveX control for WYSIWYG editing xml documents, and there's a syntax highlighed raw view using Wx::STC (Scintilla)

        We'll probably add an FTP or WebDAV api so we can access our repositories from third-party applications. Our SOAP api is fine for our application but it's next to useless if we want to access our repositories from outside our app. Still, we can reuse the code in our FTP/WebDAV api.

        I suggest using an open protocol from the beginning.

        -- simonflk

Re: [OT] Desktop applications over HTTP
by raptnor2 (Beadle) on May 05, 2004 at 01:16 UTC
    I found the PerlPlusPlugin over at CPAN, which may help. It looks like it was designed to launch Perl apps from a browser (Perl/Tk and Perl/OpenGL). It also looks like it has some security issues (for the client) if dangerous code is launched.

    http://backpan.cpan.org/authors/id/F/FH/FHOLTRY/ppl-plug-0.94.readme

    BTW, Comma looks pretty cool. I'll have to take a closer look.

    Cheers,

    John

      I found the PerlPlusPlugin over at CPAN, which may help. It looks like it was designed to launch Perl apps from a browser (Perl/Tk and Perl/OpenGL). It also looks like it has some security issues (for the client) if dangerous code is launched.
      That looks really interesting. Thanks for the link. One of the things we were trying to keep in mind during our original discussion on and off the Comma list was that we didn't want to be tied to Perl code on the client (even though I would probably opt to use wxPerl if I were the one coding on the client side). I'm going to give the ppl::plug code another look, though.
      BTW, Comma looks pretty cool. I'll have to take a closer look.
      It's certainly taken some of the tedium that goes along with developing big complex websites out of the picture for me. If you have any questions/comments/suggestions as you're taking a look, feel free to join the list and chime in. It's low traffic, but responsive.

      Thanks again!

      -- Douglas

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://350455]
Approved by kvale
Front-paged by jarich
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (4)
As of 2022-05-23 05:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (81 votes). Check out past polls.

    Notices?