To Web, or Not

Robert Hess
Developer Relations Group
Microsoft Corporation

February 8, 1999

Download Microsoft Word (.DOC) format of this document (zipped, 7.56K).

The following article, which was originally published in the Site Builder Magazine (now known as MSDN Online Voices) "More or Hess" column (now found in MSDN Online Voices, continues a series in which MSDN Online columnist-at-large Robert Hess investigates application development in the Internet Age.

I often get all sorts of interesting questions from folks. The other day the following came through:

I have been asked to put a Web system together that allows a given user to create a Microsoft Word document, and get review comments back from one or more users. What we would like to do is to store the Word document on an ASP page (with all formatting codes), allow the user to select a chunk of the document and store the chunk on the same Web page (with all Microsoft Word formatting codes still in the chunk). The user could then put their suggested changes in. After that, the user could submit the ASP page to the Web server.

This person is talking about a document-management system -- the sort of thing that companies such as Documentum, FileNet, PC Docs, and many others make their living at developing and deploying to provide the exact solution that is being described. But here is a person who has been instructed to build a customized, Web-based solution.

There are some problems and issues with this approach. To help you understand Web-based application deployment issues, I'm going to walk through this scenario and hopefully describe to you several aspects of this situation. First, I'll describe why this person is mistaken in thinking that a solution can best be implemented by a Web-based application. Then I'll describe how it could be deployed on the Web (no, that's not a contradiction). Finally, I'll touch on why this sort of application will eventually be extremely easy to implement on the Web.

Conceptually, this scenario isn't too hard to grasp. Individual pieces of this solution exist and are well understood today. A computer can easily be a repository for documents, storing them in the most simple of databases, the file system. It will manage creation and modification dates, as well as provide rudimentary document locking so that applications can avoid two people updating the same document simultaneously.

Networks provide an easy method for accessing documents in a "group" environment, often without the application even needing to know that it is dealing with files stored on the network.

The Internet, and more specifically the World Wide Web, exposes a method of network access that can easily provide information to local or remote users across a variety of different platforms. It allows a company to provide secure access to various forms of information to a worldwide employee base.

The Web environment also enables rich document rendering. With a wide variety of formatting capabilities and image handling, it allows you to make almost any type of information available.

So it really isn't surprising at all that somebody would see all of these features and capabilities, and come to the logical conclusion that they can be combined to form a rich and robust document-management system.

Let's re-work the user's original question into a design flow of the solution's required steps.

• Server-side enumeration and hyperlink access to documents and their descriptions stored on the server
• Requested documents sent to the user and displayed within the browser-client window
• The ability to "check out" the document, marking it as "locked" on the server, and to add modifications or notes
• Editing the document within the browser-client's frame
• The ability to track and manage document modifications to provide a log for later approval
• The ability to send document modifications back to the server, at which time the server version of the document is updated to reflect changes, and the lock on the document is released

Each one of the elements listed above can be provided by either direct or indirect support. The problem comes when you try to pull all these together into a single transparent solution. You either end up with a fairly complex set of steps the user has to go through to move the document through its paces, or you need to write a lot of custom server and client code (and I don't mean just HTML!) to coordinate the workflow of the document.

Now, let's take a look at each step individually:

1. Server-side enumeration and hyperlink access to documents and their descriptions stored on the server

This is easily done today through script code on the server. The list of files and their descriptions can be manually built into a Web page, or they can be extracted from a database of some sort -- or server-side components can be used to dynamically enumerate the files in a specific directory and provide links to access them. So, the functionality of this piece can be as robust as you want to make it.

2. Requested documents sent to the user and displayed within the browser-client window

This is precisely what the Web is all about. While there are some limitations in what rendering process is used to deploy the documents, there is a lot of flexibility built into this. The best solution will be one that uses well-formed HTML documents as its standard format. And here is where the kinks start to appear in what the user described. The request specifically indicated Microsoft Word as part of the solution. Since Word's current default format is not directly compatible with HTML, some decisions will need to be made on how to approach this properly.

3. The ability to "check out" the document, marking it as "locked" on the server, and to add modifications or notes

Ahhh ... now this is getting a little tricky. But conceptually, it is possible. Through user interaction on the page, it is relatively simple to activate a server-side component that "marks" the specified file as currently in use. Some of the existing document-management applications or source-code control solutions probably expose components that can be used to do this without much work. But it would also be relatively easy to develop a custom server component that could handle this. While you could do this using script code, the filesystem object, and ASP technology's Application object to manage a queue of checked-out files, such an approach will eventually get a little messy to manage. It would be better to build a custom server component in C++ from the start, thus allowing a high degree of flexibility.

4. Editing the document within the browser-client's frame

Here, we are getting a little trickier yet. We've already touched on the notion of HTML versus Word documents; this next step appears to dictate the use of Word as the interface to the document. While a link to a Word document can easily load the document into Word directly within the browser window, this level of application interaction between Internet Explorer and Word is totally in the user's control. Regardless of the page author's intent, the user can easily set things up so that Word is launched as a separate application. While this isn't a serious barrier, it is specifically not what the page author wants, because it diminishes control over the "flow" of the document and its modifications.

5. Changes are tracked in the document and managed in such a way as to provide a log of the modifications for later approval

The Word application can already provide this feature directly within its document format. If that level of functionality is enough for this situation, it is probably best to leave this as-is. However, if the user needs some level of additional functionality, a more extensive solution will be required. A clearer direction of what is needed here is necessary to determine the extent of customization.

6. The ability to send document modifications back to the server, at which time the server version of the document is updated to reflect changes, and the lock on the document is released

This is even more challenging. While both Microsoft Internet Explorer and Netscape Navigator support the notion of "file upload," which allows a user to send a file back to the server, this functionality is not an Internet standard, nor is it transparently supported by applications.

This means that when the user exits Word, there is no connection back to the server that allows Word to pass the file back and replace the original version. The base problem here is that HTTP, as currently implemented, is essentially a read-only protocol. It works great for "requesting" information, even for requesting dynamic information. But there is nothing in the existing HTTP protocol that specifically supports writing files back to the server.

A very simple overview of the abilities and limitations of HTTP can be found at on the World Wide Web Consortium (W3C) Web site.

This limitation is one of the primary stumbling blocks to the type of functionality that many application developers want to expose on the Web. Applications such as FrontPage® and Visual InterDev™ have been able to overload this "request/response" protocol to allow limited "get/put" data transfers, but only after a lot of hoop jumping. This also requires specific additional applications and DLLs to be loaded onto both the server and the client.

But if you are willing to develop the appropriate additional components, this too can be solved -- just not terribly easily. This final step is probably the most critical piece of the entire solution, and needs to be thought out carefully to ensure that the rest of the application falls neatly into place.

Hopefully this example has provided a good outline of how existing Web/Internet expectations can start developers down this slippery slope, and how a well-designed solution is probably a larger and more difficult task than was anticipated. My personal recommendation is to first check with existing product offerings from companies that specialize in document management, and to see how close their products will come to solving this problem. Only if there are critical requirements that aren't addressed should you dedicate the resources to building a custom solution.

But what about the future? How is the Web evolving to deal with this scenario differently?

As I indicated above, one of the key stumbling blocks that people are constantly bumping into is the limitation of HTTP to supply a rich bi-directional file-transfer model. Work is underway to address this, and it actually is very close to implementation.

The primary effort is known as WebDAV, or Web Distributed Authoring and Versioning. WebDAV is a set of extensions to HTTP 1.1 that will enable people to read and write documents over the Web. The extensions allow users to share and work with server-based documents regardless of the authoring tools, platforms, or the types of Web servers on which the documents are stored.

You can find more information about WebDAV at the Internet Engineering Task Force Web site.

In the very near future you'll be seeing support for WebDAV in a wide variety of offerings from Microsoft and other companies. Once this support is integrated into the common browsing experience, the scenario we've discussed becomes a lot easier to implement. Product offerings by document-management companies can then focus on the specific issues of document management, without having to deal with data storage, file transfers, and user-interface issues.

You'll also find that as more applications focus on the Windows DNA architecture, it will become easier to deploy custom solutions that use and integrate the functionality of several different applications. The combination of modular design, scriptable interfaces, and targeted deployment greatly increases the ability of developers to take control over the direction of their solutions.

Robert Hess is an evangelist in Microsoft's Developer Relations Group. Fortunately for all of us, his opinions are his own.