Skip navigation

Tag Archives: Content Management

For some strange reason I can still remember the phone call I received six years ago. It came with a somewhat strange assignment which is probably why I remember the call. I was sitting in my office quietly putting together a requirements document for my next release when my manager rang me up. He needed me to hop on a plane the next day and head down to Santa Cruz. It seems the CTO forgot to tell him to send someone down to a “WebDAV Interoperability Event” being held at UCSC. Clearly, I had drawn the short straw that day. My manager not only threw me the assignment but in the same call mentioned that I was now responsible for our platform’s WebDAV capabilities. So I scrambled to get a ticket, explain things to my wife (truly the most difficult task I had that week) and the next day was driving from San Jose airport down to the campus.

Back in 2004 my knowledge of WebDAV was pretty slim. As I really hadn’t paid much attention to it. At the time I was pretty sure I could spell WebDAV and that it had something to do with sharing files across the web. It was ironic that I hadn’t given it much thought up to that point as I (along with the browser-using public) had been unknowingly using it for quite some time.

The concept of WebDAV is straightforward and, frankly, not particularly mouthwatering–especially to a technofile like myself. That is both the strength and the beauty of this technology. If you read my earlier post on PDF/A you will see that I’ve visited this theme before. As I’ve come to realize after a trip or two around the block sexy software might sell but usable software endures.

Back in 2004 when I showed up at the interoperability event my job was to take my demo system and see how many of the other vendors could connect their WebDAV clients to my system. As I remember there was a sordid (grin) cast of vendors. I was in the room wth folks from Apple, Microsoft, Computer Associates, Xythos and a few others including a UC Santa Cruz team who had built their very own WebDAV client. Leading this event was a down-to-earth professor by the name of Jim Whitehead. Because I didn’t know much about WebDAV at the time I had no clue it was he who spearheaded the WebDAV movement and would become known as the “Father of WebDAV”. One thing I did note was that he was a man with many balls in the air and he seemed to be supervising a number of disparate groups that week. We were one of at least two or three big efforts he had on the go. Despite his busy schedule he still gave this the time it deserved AND even went out with us for a pint or two one evening.

We gathered in one of the computer science department’s classrooms and the environment was more like that of a 3rd year study group working on a problem set then a gathering of software professionals. That was actually pretty cool because any tension was quickly lifted and we were soon cracking geeky jokes with one another. I admit they were VERY geeky as I remember the punchline to one of them being something like “Tell him to use ‘grep'” (much laughter ensued).

A Brief Explanation Of WebDAV

Although there are a number of sources on the web explaining WebDAV at various levels (like here) I figured I’d belt out a background here.

As I have mentioned WebDAV was developed to help content authors share documents across the web. While today this doesn’t sound very earth shattering back in the 1990s when the web was starting to ramp up the lack of content sharing functionality was a blatant sore spot for the web authoring community. This made geographically-distributed content collaboration manual and clumsy.

WebDAV is meant to extend HTTP from read-only to read/write. In 1996 the WorldWideWeb (i.e. HTTP) was primarily a presentation-only affair. Users were allowed to browse to a website and view it’s contents and that’s it. File sharing had to be done through another mechanism such as FTP. This would mean that a separate FTP server would need to be set up and maintained, folders and permissions added, accounts created and so on. On the authoring side, users would need to take manual steps to move the files back and forth. WebDAV was meant to remove these manual steps and allow access directly through an HTTP client such as a browser.

The problem at the time was that HTTP was not broad enough to support this desired functionality. Remember that HTTP is a specification–effectively a contract between web browsers and web servers– and in order for everyone to get along we must follow the rules of this specification. To solve this, it was proposed (to the W3C) and accepted that the HTTP specification would be augmented with elements that enabled “read/write” behaviour. WebDAV was conceived but not yet born and I say this because it is one thing to write a spec but another (big) thing to actually implement it and even another (bigger) thing to become widely adopted. Eventually WebDAV acheived all of this.

WebDAV stands for “Web Distributed Authoring and Versioning”. The original goal of this specification was to provide basic document management functionality. WebDAV enabled web servers to now be used as content management servers as well. This would mean that anyone with an HTTP client (e.g. a browser) could now collaborate with one another (i.e. share, approve, edit, etc files) with much less overhead.

That was the plan and it was supposed to be mostly done in a single release of the spec. However, that isn’t exactly how this all played out. While it may have appeared a straightforward task there was surprisingly a lot of work to be done to cover off the original vision. Rather then hold things up the WebDAV working group chose to segment the specs. The initial phase of WebDAV was stripped down and did not include versioning. Without versioning in place it meant that WebDAV was really to behave more like a file system (where people can freely copy, move and over-write files) then a collaborative tool. While you might think this was a big loss it was still highly effective. In fact, it was this initial edition of WebDAV that most vendors adopted and have stayed put with.

I remember while at UCSC Jim walking a lot about “Delta-V”. As I learned Delta-V was an add-on to WebDAV and completed the HTTP extensions for versioning. I’m not sure whether the initial version of WebDAV gave us most of what we wanted or if the Delta-V add-on proved too costly to implement but most vendors have not implemented the versioning aspect to this day.

So What Happened?

WebDAV got itself widely adopted. There are a number of key reasons for it and I will go through these.

First, WebDAV functions across HTTP. This is the true elegance of the original vision. There is a browser on everyone’s desktop, laptop, mobile phone and belt buckle (OK..maybe not yet). With that, WebDAV opens itself up to a massive number of users right out of the gate. If I were a browser vendor why wouldn’t I want to give my browser the capability to be used for file sharing–the idea is that the user stays put in my browser for as many of her daily tasks as possible. This symbiotic relationship meant that Microsoft, Netscape and Apple (and later Mozilla) were motivated to adopt WebDAV in order to encourage usage. Remember back in the late 90s and early part of this decade there was still a blood-soaked popularity contest raging among browser vendors. Microsoft even upped the ante and WebDAV-enabled both Windows Explorer and Microsoft Office. With Windows Explorer supporting WebDAV it should go without saying that this opens up WebDAV usage to an even larger group of users (talk about world-wide adoption!). This is what I mean by the fact that I was using WebDAV without even knowing it. While in Windows Explorer a WebDAV folder looks and behaves just as any other Windows folder. I will say that the only thing I have on my wish list here would be for Windows Explorer to present thumbnail images from a WebDAV folder…but I don’t see that happening anytime soon.

The truth is that it was the adoption by Microsoft that took WebDAV from an neo-academic pursuit with mild market adoption through to complete viability and where the movement really took off. It is this continued support by Microsoft in the present day that ensures WebDAV remains a healthy standard and will be for the foreseeable future.

In the course of things another significant round of non-Microsoft adoption occured. Content authoring tool vendors such as Adobe capitilized on WebDAV–this was expected as it was for these users that WebDAV was originally envisioned. Not to be overlooked are the ECM vendors (indeed!). As my presence in UCSC indicated the ECM vendors were also implementing WebDAV. This was a no-brainer as it effectively gave the ECM vendors a free-lunch when it came to Windows browser and desktop integration. All an ECM vendor had to do was provide a WebDAV service and–POW–Windows/Internet explorer could be used as a ECM client. This is exactly the type of synergy that Jim’s Interoperability Event was meant to promote and I was on the hook to record and report all of the glitches that the other software vendors had in connecting to my repository. In fact, to this day the ECM vendors are continuing these interoperability events as they develop their CMIS interfaces.

I can’t tell you how many times I’ve put together a concept system or demo where I’ve simply set up a windows folder on the desktop, dragged in a couple of documents and (poof) these documents are instantly entered into the ECM repository complete with index values and approval lifecycle all ready to go. I am able to combine WebDAV’s UI simplicity with the advanced features of the ECM repository to improve people’s productivity while keeping their lives very much the same.

Here’s a simple example. Let’s say an HR specialist is responsible for keeping all of a company’s internal policy documents up-to-date. They might do the following:

1) open the document
2) make the edits
3) save the doc
4) open an email, add the doc in the email as an attachment
5) send email to manager/team lead for approval
6) Once approval is received send to the publishing team
7) publishing team posts to internal site/location

With WebDAV and (most) ECM systems I can take that very same process and automate it (without writing a scratch of code) so that steps 4) through 7) are handled entirely by the ECM system (with a complete audit trail). The rub here is that I can do it without any of the participants in this process need to learn any new tools! In the new world I would create the author simply saves the document back to the WebDAV folder and moves on to the next task. Everything else is orchestrated and executed by the ECM platform. If you are doing one document a day this isn’t such a big deal. Content authors who work with dozens of docs with tight deadlines very quickly realize this potential. With WebDAV and ECM you can have your cake and eat it too. 🙂

Low-tech users who still print out their emails and think Google is the real name of the internet love this sort of thing as their Windows-explorer world doesn’t change. IT groups love it because the users love it and their overhead doesn’t get worse. Like I said, WebDAV is neither sexy nor cutting-edge but it is easy, well-supported and transparent.

Over the years I’ve heard a lot about the demise of WebDAV. I hear that it is old technology or too static to live on. Pish-posh. The truth is that WebDAV is like the air we breathe, necessary to function and invisibly there for us. Looking at the ECM landscape I see that every major ECM vendor from IBM (P8 and CM8) to OpenText (LiveLink) to Microsoft (Sharepoint) and so on continues to provide WebDAV support with each new release. Among the ECM vendors WebDAV is simply an ongoing requirement in the price of entry to the market. Unless the planet tosses out HTTP there will always be a place for WebDAV.

Advertisements