|
Distributed Authoring on the Web with the bscw shared Workspace system
|
| bet | 7/9 | | Sana | 22.07.2021 | | Hajmi | 34,45 Kb. | | #15603 |
We have described the BSCW system and the application-level solutions it provides for distributed authoring in terms of document uploading and version management. (In fact, most of the features described have been used to prepare this paper. Drafts have been created, discussed, modified and finally edited using BSCW involving several participants at the University of Irvine, CA, and GMD, Germany.) In this section we discuss these solutions with respect to current and future Web standards and the activities of the W3C Working Group on Distributed Authoring and Versioning, and its proposed standard of extensions for Distributed Authoring (Goland et al., 1997).
The lack of a standard, accepted method of file upload using HTTP, and support from Web agents like browsers and servers, is the most obvious problem for distributed authoring. In some cases this has led to the situation where vendors support different methods for similar purposes, e.g. MIME multipart method in Netscape Navigator for general file upload and HTTP PUT in Netscape Gold for HTML document publishing. The lack of standard support has required the development of helper applications for BSCW to handle file upload independently of a Web browser, but this solution is hardly ideal - a helper has to be installed by every user who doesnÕt use Netscape Navigator. In addition the helper has to handle aspects such as authentication, upload via a proxy server etc., which the browser can already handle using existing functionality. The browser is the logical place to provide file upload in a standardized manner, for publishing documents of any kind not restricted to HTML.
It remains to be seen which of the two methods for uploading described here (or others discussed by the W3C working group) is most appropriate. MIME multipart allows sending multiple documents over a single HTTP connection, while current implementations of HTTP PUT use separate requests for each document. The MIME multipart format, however, originates from work in email and this is reflected in implementation difficulties when supporting it on top of HTTP. 2 Perhaps support for more persistent HTTP connections as specified for Version 1.1 of the HTTP protocol (ÔKeep-aliveÕ) will allow efficient implementations of the PUT method.
The case for standardized support of file uploading is clear and is being driven by (among others) vendors of remote HTML editing tools to allow their editors to operate with all common Web servers. If this standard was then supported by Web browsers and servers it would certainly ease some of the problems for developers of applications like BSCW. The case for version management is perhaps more complex, however. The different ways in which versioning can be supported, and the different components of a modern version management system, raise questions as to what extent version management should be supported by HTTP and other Web standards (such as APIs), and what remains the responsibility of an application developer.
From experiences with BSCW we would argue that even a simple check-in/out model requires more than adding request methods to the HTTP protocol, involving archiving, history, synchronization and more. With respect to collaborative authoring, we highlight the importance of the history function in particular, and the provision of awareness information more generally.
The simple locking mechanisms as proposed by the WEBDAV Working Group (Goland et al., 1997) do not seem to address these issues sufficiently. They suggest a strict locking mechanism on resources to avoid the Òlost-updateÓ problem.à3 Locks can only be released by the owner of the lock or by setting a time-out value allowing the system to release the lock after a period of time. The proposal does not yet forsee any provision to pass the ownership of a lock.
Our experiences with the BSCW system suggest a much more optimistic approach to concurrency control. Strict locking as introduced by traditional database systems have turned out be too restrictive in collaborative applications. Resources might easily be locked for a long period of time and thus unavailable for other members in the cooperation process. The use of time-out values to release a lock often fails due to the difficulty of assignment of an approprate time-out value.
However, attempts to support more flexible approaches of concurrency control have the potential to complicate Web standards and thus limiting their utility to application developers. Clearly, with the current trend towards increasing the scope of the Web to include distributed, collaborative authoring and maintenance of Web sites, there is a need for some standards work in this area if numerous, proprietary implementations are not to proliferate with the next generation of remote publishing environments. With respect to Web-based concurrency control and version management, the question of what to standardize is as important a question as how.
|
| |
