Usability - Productivity - Business - The web - Singapore & Twins

Round-Trip editing experience in web browsers

Our applications are increasingly moving to http(s) based interfaces, that is HTML(5) or apps. Besides the irony, that we abandon client applications on desktops to reintroduce them on mobile devices (is ObjectiveC the VB of the 21st century?), that's a good thing
However from time to time, unless you live in the cloud, we need to integrate into extisting standing desktop applications, mostly but not limited to Office applications. The emerging standard for this is clearly CMIS. Most office packages do support CMIS in one way or the other today. However it does not integrate into file managers like Finder, Explorer or Nautilus (at least not to my best knowledge at time of writing). One could sidestep that shortcoming by using CmisSync, but that only works as long as you have enough local storage and corporate security lets you do so.
Another challenge to sort out: once applications that "surround" Office documents are all HTML based, one should be able to commence editing directly from clicking something in the web based business application. So the criteria are:
  1. Ability to interact with documents using File-Open in applications (ironically the ODMA standard got that working more than 15 years ago, but died due to vendor negligence)
  2. Ability to interact with documents using the default file navigator (Finder, Nautilus, Explorer, mobile devices)
  3. Ability to have a full roundtrip editing experience in the browser. A user clicks on a button or link (or icon), the document opens, editing commences. When hitting the save button the original document is updated, so when someone else clicks on that link the latest updates can be seen there
Once you want to support non-Windows platforms (and work in multiple browsers) ActiveX (the approach Microsoft choose) is ruled out. Enter webDAV. It covers #1 and #2, with some difficulties to a point that the commercial package for webDAV on IBM platforms (Connections, Domino, Quickr) doesn't support Explorer on Windows 7, a flaw it coincidentally shares with a much older package, but not with the current project.
The challenge for #3: Whenever a browser encounters an URL with http(s) it will try to handle that target. If the mime type is not directly handled by the browser it will trigger the download of the file and hand it over to the application (with or without a dialog, depending on your settings). When the user then interacts with that document, it is the downloaded version in a temp directory. Changes are not send back!
On the other hand: if a user opens a file directly in the office application by selecting a webfolder, a mounted file system or directly specifying the URL, then roundtrip editing happens since the office applications check the URL for webDAV capabilities (I had some fun with Apache's TCPMon figuring that out).
The solution for this puzzle is to use a different protocol. Protocols are simply indicators for the operating system what application is in charge. The commonly known are http(s), ftp, ssh, mailto (and gopher for the old generation), but also notes or sap (and others).
For my approach I used webdav(s) as protocol name. On Windows protocols live in the registry, on other operating system in configuration files.
Once configured correctly a little helper application would pick up the webdav(s) URL from the browser, check for the default application and launch it with the URL converted to http(s) on the command line - and voila roundtrip editing happens (check out the project).
Of course some stuff needs handling: the office application doesn't share credentials with the browser, so SSO or other means need to be in place to ensure smooth user experience. Also MS-Office not only probes for webDAV capability of that URL, but also if that server behaves like SharePoint by probing an extra URL (some enlightenment what it is looking for would be nice).
On Linux (and probably OS/X) one doesn't need a C++ program to figure out the right application, a shell script does the trick.
#Launches a URL with the application it was made with rather than the browser
#Good for webDAV servers
#What do we support - adjust to your needs
supported_extensions= "odp odt ods xls doc ppt txt pdf"

#Get the http(s) url from webdav(s)
FULLURL1= ${1/webdav:/http:}
FULLURL= ${FULLURL1/webdavs:/https:}

#Get the extension

#check if the extension is a supported file type
for check in $supported_extensions
    [ "$check" = "$EXTENSION" ] && SUPPORTED=YES && break
if [ "$SUPPORTED" = "NO" ]; then
  echo "Sorry, we don't allow $EXTENSION on webDAV urls"
  exit 1

# Make a sample file (temp only)
SAMPLENAME= $HOME /~webdavhelpersample. $EXTENSION

#Get the mime type
CURMINE=$ (xdg-mime query filetype $SAMPLENAME )

#Remove the temp file

# Retrieve the desktop file from mime type
CURDSK=$ (xdg-mime query default $CURMINE )

#Find the desktop file
if [ -f /.local /share /applications / $CURDSK ]; then
      TRUEDSK= /.local /share /applications / $CURDSK
elif [ -f /usr /local /share /applications / $CURDSK ]; then
      TRUEDSK= /usr /local /share /applications / $CURDSK
elif [ -f   /usr /share /applications / $CURDSK ]; then
      TRUEDSK= /usr /share /applications / $CURDSK
    echo "Sorry no executable found for $1"
    exit 1

#Grab the executable and add the URL
WHATTODO=$ ( grep "^Exec" $TRUEDSK | head -1 | sed "s/Exec=//; s^\%U^$FULLURL^;" )

#Run it
exit 0
As usual YMMV!

Posted by on 28 March 2013 | Comments (0) | categories: Linux Software


  1. No comments yet, be the first to comment