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. As usual YMMV!