WO2002033575A2

WO2002033575A2 - Concurrent file access

Info

Publication number: WO2002033575A2
Application number: PCT/GB2001/004653
Authority: WO
Inventors: Joanne Clark; Peter Ward; Mark Norman
Original assignee: Chasseral Limited
Priority date: 2000-10-18
Filing date: 2001-10-18
Publication date: 2002-04-25
Also published as: WO2002033575A3; GB0311372D0; AU2001295748A1; GB2390713A; GB2390713B

Abstract

Shared file access may be achieved in a computer network using the following steps; storing the file in the form of a plurality of blocks, delivering the file to a first client application by delivering the block contents to the client application, monitoring user editing actions performed on the delivered file in the first client application, during editing of the delivered file, locking a stored block which corresponds to the portion of the file being edited to prevent other client applications editing the same block, and updating the locked block with edits performed by the first client application, after editing of the locked block is finished, delivering the updated block to other client applications.

Description

CONCURRENT FILE ACCESS

Field of the Invention

This invention relates to methods and apparatus for sharing file access in a computer network.

Background of the Invention

The Internet has the potential dramatically to improve the productivity of teams through collaboration. However, the sequential operation of conventional office workstation applications prevents that potential from being fully realised. Conventional applications allow sequential access to documents in the sense that, each user works of their own personal copy of the document and then passes it on to other users for their own modifications. An alternative strategy is to allow separate collaborative workers to prepare agreed separate parts of a document and then to attempt to merge the results into a single document. This second approach is often difficult to achieve efficiently and can result in changes in style and in inaccuracies between the different sections of the document.

Sequential working stems from the fundamental limitations of the underlying file system. The underlying file system does not permit more than one user to have write access to a file. Thus conventionally, other users may view documents concurrently but this is on a "read-only" basis and thus only one user may perform edits on the original document.

In order to overcome the problems caused by sequential file access, proposals such as document management, workflow, collaboration and imaging systems have been made in which rather than provide genuine concurrent access to documents, the systems manage the versions and distribution of a document within a collaborative team of users. Such solutions whilst mitigating the problems caused by sequential file access, do not allow genuinely free collaborative work in between users of a single document. It will be noted that the use of the terms "document" and "file" herein are intended to encompass any application data such as spreadsheet data, data for a presentation document, a web page, an electronic form, an image or sound file, or a word processor document.. The term "file" is not limited to a data structure stored on a non-volatile storage medium such as a disk and includes any stored representation of data which may be worked upon by a user via application software.

Summary of the Invention

According to a first aspect of the invention there is provided a method of sharing file access in a computer network comprising the steps of storing the file in the form of a plurality of blocks, delivering the file to a first client application by delivering the block contents to the client application, monitoring user editing actions performed on - the delivered file in the first client application, during editing of the delivered file, locking a stored block which corresponds to the portion of the file being edited to prevent other client applications editing the same block, and updating the locked block with edits performed by the first client application.

Preferably, the method further includes delivering the updated block to other client applications which have the file open. In this way, the other client applications are kept up to date with the most current version of the file.

In a second aspect, the invention provides a method of enabling a client application to provide shared file access in a computer network comprising intercepting a file open request in the application, receiving a file from a server as a plurality of blocks, opening a file in the application and populating the opened file with the contents of the delivered blocks, intercepting user editing actions performed in the application, locking a block in the server which corresponds to a portion of the file being edited by a user via the application, updating the locked block in the server with the user edits when the user has moved to another portion of the file, and distributing the updated block to any other client applications which have the same file open. This aspect may be embodied in the form of a software wrapper, for example, for a legacy application. Thus by installing a wrapper on an existing application, the application may be "concurrency enabled". Alternatively, an application may be written explicitly with the method of the first aspect in mind and thus the invention also provides a workstation in a computer network operable to receive a file from a server as a plurality of blocks, open a file in a workstation application and to populate the opened file with the contents of the delivered blocks, record user editing actions performed in the application, cause the server to lock a block in the server which corresponds to a portion of the file being edited by a user via the application, and send updates for the locked block to the server which include the user edits when the user has moved to another portion of the file.

In a further aspect the invention provides a computer program for a client in a computer network embodying the steps of receiving a file from a server as a plurality of blocks, opening a file in the application and populating the opened file with the contents of the delivered blocks, recording user editing actions performed in the application, causing the server to lock a block in the server which corresponds to a portion of the file being edited by a user via the application, sending updates for the locked block to the server which include the user edits when the user has moved to another portion of the file, and receiving updates from the server which represent changes made to the file by other users in communication with the server.

The storage of the file in blocks in accordance with the first aspect, will generally be carried out by a server which may, for example, be a file server in a client/server environment or a workstation in a peer-to-peer network configuration. Further alternatives are the provision of the document store and a server based in an Internet environment.

Thus the invention also provides a server in a computer network operable to deliver a file to a client application as a plurality of blocks, receive a lock request from a client application, check that the block requested to be locked is not already locked by another client application and to lock the requested block if it is not already locked, receive an updated block from the client which requested the block to be locked, and distribute the updated block to any other client applications which have the same file open. In another aspect, the invention provides a computer program for a server embodying the steps of delivering a file to a client application as a plurality of blocks, receiving a lock request from a client application, checking that the block requested to be locked is not already locked by another client application and locking the requested block if it is not already locked, receiving an updated block from the client which requested the block to be locked, and distributing the updated block to any other client applications which have the same file open.

In a further aspect, the invention provides a storage block for containing a portion of a computer file comprising an ID field, a contents field and a style field.

Brief description of the drawings

Preferred embodiments of the invention will now be described by way of example with reference to the drawings in which:

Figure 1 is a schematic block diagram of a computer network in accordance with the invention;

Figure 2 is a schematic block diagram of the hierarchical block storage of files in accordance with the invention;

Figure 3 is a schematic block diagram of information flow between a client and a concurrency server;

Figure 4 is a schematic block diagram of information flow between a client and a concurrency server;

Figure 5 is a schematic block diagram of information flow between a client and a concurrency server;

Figure 6 is a schematic block diagram of information flow between a client and a concurrency server; Figure 7 is a schematic block diagram of information flow between a client and a concurrency server;

Figure 8 is a schematic block diagram of information flow between a client and a concurrency server;

Figure 9 is a schematic block diagram of information flow between a client and a concurrency server;

Figure 10 is a schematic block diagram of information flow between a client and a concurrency server;

Figure 11 is a schematic block diagram of information flow between a client and a concurrency server;

Figure 12 is a schematic block diagram of information flow between a client and a concurrency server;

Figure 13 is a schematic block diagram of information flow between a client and a concurrency server;

Figure 14 is a flow chart showing the overall operation of the system of Figure 1 ;

Figure 15 is a schematic flow chart showing the steps taken by an application wrapper in accordance with the intention; and

Figure 16 is a flow diagram showing the steps carried out by a server in accordance with the invention. Detailed description of the preferred embodiments

Figure 1 shows a plurality of client applications 2 such as Microsoft Word (trade mark) Star Office or Word Perfect (trade mark). These "legacy" applications are interfaced via wrappers 4-1 and 4-2 to a network such as an Ethernet network, 6. The new and custom applications interface directly to the network 6 since (as will be described in detail below) such applications effectively include the functionality of the wrappers 4-1 and 4-2.

The network 6 allows the applications 2 to connect to a concurrency engine 8 via an application program interface (API) 10. The concurrency engine stores documents for editing in a format described in detail below. The elements of the documents are stored using extensible mark up language (XML) objects in an XML repository 12.

A further network 14 which may, for example, be another Ethernet LAN in a WAN (The network 14 may also be another part of the network 6), interfaces with the API 10 and also with another set of applications 16. The applications 16 are arranged for the display of documents stored in the concurrency engine 8. Thus a wrapper 4- 3 may be used to provide an interface for legacy applications such as Microsoft Word (trade mark), Star Office and/or Power Point (trade mark). Alternatively the document may be formatted by the engine 8 and API 10 in hypertext transfer protocol (http) format (in which case it may be transmitted to HTML, WAP or PDF enable display devices), extensible mark up language (XML) which is interpretable by existing applications such as Quark Express or in XML transformed by applying extensible style sheet language (XSL) to modified XML or some other format.

The purpose and interaction of the elements shown in Figure 1 will now be described in detail.

It will be appreciated that the networks 6 and 14 need not be LANs but may, for example, be portions of an Internet, Intranet or Extranet. The concurrency engine 8 similarly may be located on a file server, on a workstation in a peer-to-peer network or on an Internet server such as a web server. All that is required is that the applications 4 are able to send and receive data to the API 10. Documents are stored in the engine 8 as blocks. With reference to Figure 2, a block is an element of a document such as a paragraph of text, a table, a table cell, or an embedded object, e.g. a picture.

If a document can be represented as a structured tree, a block represents each structure level. A container block 18-1 or 18-3 is a "parent" block which itself contains additional blocks or "children" 20-1 and 20-2 and 20-3 respectively. The document's root block 22 is the "parent" of the first level of content of the document, which in a simple unstructured document would be its entire contents. The title of the document , its ID and a list of style definitions is stored in a Document object 17.

Connecting To The Engine using CORBA

A client process 2 first connects to a specific concurrency engine 8. The engine 8 is located via a URL which points to a text file containing a unique IOR (Interoperable Object Reference).

On connection, the client 2 asks the user for a username and password and sends these to the engine 8 as a login request. The username and password may be internal to the engine, or authenticated using an external security service, e.g. NDS, LDAP, NT, etc.

In response, the engine 8 creates a new thread and Corba object for the connected client 2 and returns the unique IOR for this object to the client. The client 2 then makes all further requests to that object.

If the client 2 requires updates made by other concurrently connected clients, it requests a "broadcast IOR" from the engine. The engine creates a further thread and Corba object which it will use to send updates made by other clients 2 to this client 2. The engine returns the unique IOR for this object to the client 2 and the client 2 makes requests for broadcast updates from that object.

Once thdse three steps are completed, the client 2 is considered to be connected to the engine 8. If any of the steps fails, the client 2 is disconnected from the engine and displays a message to the user along the lines of "Failed to connect to the Concurrency Engine."

Connecting to The Engine - Non-Corba

The above section describes the initial connection made by a CORBA client. In the preferred embodiment the engine also supports direct connection from Java clients. In such a case, the client connects to a specified port on the machine which is running the Engine. Two parallel sockets connections are created, one in each direction. The client uses one to make requests of the Engine. The Engine uses the other to broadcast changes made by other clients.

Available Document List

The client 2 then requests a list of documents to which the logged in user has access. These are returned as a list of owned documents (documents this user created), a list of documents to which the user has write access, and a list of documents to which the user has read-only access. A unique document ID number and a document title is returned for each listed document. Preferably the document list is displayed as the contents of an extra storage drive in the operating system shell (e.g. Microsoft Windows Explorer and the Windows File Dialog).

Modifying Document Access The owner (creator) of a document has control over which users may access the document. Other users can be granted write access or read-only access by calling the API 10, sending the document ID and the name of the user to be added, and setting a flag to read or write. Also, access can be removed by calling the API 10, sending the document ID and the name of the user to be removed. Similarly, a document can be made read-only to everyone who has access to the engine 8 by calling the API 10 and sending the document ID. This global access can also be removed by calling the API 10 and sending the document ID. Global changes may also be made for all users of a particular document. If the user(s) concerned are connected when their access is changed, the engine 8 notifies the client which then displays a message to the user along the lines of "You have just been granted access Jo New Document". In the preferred embodiment, the access right modification functionality is built into a dialog which is opened by an extra menu option.

Creating a Document

The client requests newDocument and the engine creates an empty document in the database 12, owned by this user, and returns a unique ID number and unique initial default title "New Document", "New Document 2", etc.

Opening a Document

With reference to Figure 3, the client requests getSummaryDocDetails, sending the ID of the document to be opened. The Engine returns the name of the document's creator, the number of users who have write access to this document and either the number of users who have read-only access, or a flag indicating that everyone has read-only access. It also returns the number of checkpoint versions of this document. (A checkpoint is a read-only snapshot of the document as it was at a moment in time.) Finally, the unique ID of the root block of the document is returned.

Lists of the names of the users with access to this document and a list of the unique ID's of the checkpoints can be retrieved with getActualDocDetails (Figure 4).

With reference to Figure 5, the contents of the first structure level 18-1 , 18-2 and 18- 3 of the document are retrieved with getDocumentBlocks, sending the document's ID. The engine 8 returns the number of styles which may be applied to that document (In Word, the contents of the drop down list in the Formatting toolbar containing "Normal", "Body Text", "Heading 1", "Heading 2", etc.). It also returns the number of blocks in the first structure level of the document.

With reference to Figures 6 and 7, the actual styles are retrieved with getXMLEIementArray and the blocks are retrieved with getServerCachedTextBlockArray. Each array element relates to a block and for each block represented in the array, the information returned is: unique block ID, block text, name of style attached to block (may be blank), and a flag indicating whether block is a container. The contents of a container block are retrieved with getChildren, sending the ID of the block. This call must be followed by getServerCachedTextBlockArray, as for getDocumentBlocks.

In the Word Wrapper client 4-1, the retrieved paragraphs are inserted into the Word document, via Word's own COM API, building up a document in Word's memory. A .doc file is not created. The ID of each block is hidden in Word's "Field Codes".

Once getDocumentBlocks is called by a client, the Engine will send it all changes made to that document by other connected clients, immediately as they occur. Requests to change the document made by the client and notifications of changes made by other clients do not interfere with each other, they can happen concurrently because there are two parallel client-Engine connections, one in each direction.

Modifying a paragraph When a user attempts to modify the document for example by typing a character, pressing the return, delete or backspace key, cutting part of the text, pasting text, or selecting a menu option such as Insert, or changing a paragraph's style, the client requests a lock on the current paragraph, with requestLock (Figure 8), sending the ID of the block which corresponds to the paragraph which is being edited. If the relevant block is not already locked by another user, the Engine locks it in the database and returns "success", otherwise, the Engine returns the name of the user who holds the lock.

If the paragraph lock is refused by the Engine, the client ignores further key strokes, except navigation inputs such as arrow key keypresses, until the user has moved to a different paragraph. The client displays a message to the user such as "This paragraph is being modified by xxxx".

If the paragraph lock is granted, the user can continue to modify the paragraph and all other users are locked out of it, until the user either navigates out of the paragraph, or selects "Save" from the menu or toolbar. At this point, the changes to the paragraph are sent to the Engine with updateBlockTextAndlnfo; (Figure 9) sending the block ID, the new text, the new style of the paragraph, and the ID of the previous paragraph (block) in the document (this indicates the position of the block in the document). The Engine will store the update in the database, unlock the block, return a status code indicating success or failure of the update to the client, and will broadcast the change to all other connected clients who have this document currently open.

The preferred embodiment provides support for styles at sub-paragraph level, e.g. applying "bold" or "italic" to one or two words in a paragraph.

Moving a Paragraph

Cut and paste: When a paragraph is cut, deleteBlock (Figure 10) is called, sending the ID of the paragraph. If the paragraph is not already locked by earlier modifications, the Engine will lock the block and mark it for deletion. It is not actually removed from the database at this point, but it is removed from the document. If the block is then pasted, the block is then re-inserted using pasteBlock (Figure 11), sending the ID of the block, the ID of the block immediately before it in its new position (-1 if it will be the first block in the structure level), the ID of its parent block in the document structure (this will be the document's root block if the document is unstructured), and the ID of the document.

The ID of the block immediately before the reinsertion point is used to indicate the block's position in "text editor" and "newspaper" format only. In "whiteboard" format, the information sent is the block's x, y, width, height. In "table" format, no positional information is sent because the cell's position in the table is fixed. These different formats are described later in this document. The Engine will broadcast both deleteBlock and pasteBlock events to other connected clients who have this document open.

If the block is not pasted into a new position, it will be permanently removed from the database after this client has disconnected.

If the "cut" operation is reversed by the user, pasteBlock is called to return the block to the database. Drag and Drop:

When the user starts to drag a whole paragraph, the client calls requestLock if the paragraph is not already locked. If the lock is refused, the paragraph cannot be moved. When the paragraph is dropped in its new position, nothing happens until the user navigates to a different paragraph, at which point updateBlockTextAndlnfo is called in the way described above in connection with "modifying a paragraph".

Inserting a Paragraph

When a user inserts a new paragraph, no action is taken by the client until the user navigates out of the paragraph. Once this has happened, updateBlockTextAndlnfo is called, with a special flag indicating a new block. The engine 8 returns the ID which it has assigned to the new block and broadcasts the new block to other, connected clients with that document open.

When the user pastes a paragraph which has been cut or copied from this or another document, pasteBlock is called as described above in connection with "Moving a Paragraph".

Removing a Paragraph

When a user removes an entire paragraph, deleteBlock is called, sending the ID of the block to the engine 8. If the user then reverses the removal, pasteBlock is called to put it back again.

Tables

Tables are stored as a special type of block whose children are the cells of the table. If the table itself is modified e.g. add row, change line style, etc, the table block is locked with requestLock. To change the table style updateBlockTextAndlnfo is called once the Table is finished with. To insert or remove rows and cells, insertTableRow, insertTableColumn, removeTableRow or removeTableColumn are called. If one ceil of the table is modified, the block representing that cell is locked with requestLock, then updateBlockTextAndlnfo is called once the user leaves the cell. When calling updateBlockTextAndlnfo on a table cell, the previous block ID is irrelevant, as the cell's position in the table is fixed.

Converting an Existing Document

An existing document, (such as a Word document stored in a .doc file) can be imported into the engine by opening it in the existing application and selecting a special menu option "Concurrency Enable" which is inserted by the wrapper 4-1 , 4-2 or exists in the new or custom application 2. The client calls newDocument (Figure 12), then converts the document into XML and calls importFromFile (Figure 13), sending the document ID as returned by newDocument, and the XML as an array of strings. The engine 8 returns "success" when the document contents have been saved. At this point, the wrapper 4-1 , 4-2 shuts the document and reopens it from the engine 8.

Description of Document Structure and Presentation In the present invention, documents are stored in blocks. There are two basic types of block; a container which contains other blocks, and a text block which contains text. Other special block types are described below. A container flag (which is not stored in the database), is used to denote a container block when transferring information about a block between the server and a client.

As noted above, a block can represent any part of a document. In a text only document, blocks represent paragraphs of text. In Word, a block which has a Heading style applied to it is considered to represent a structure level in the document, and all blocks between it and the next block in the document with the same style attached are considered to be its children. This is very useful when loading a very large structured document over a dial-up connection, because the document can be loaded one section at a time as the user navigates through the document, by calling getChildren. The user does not need to wait several minutes while a multi-megabyte document is downloaded but instead can navigate quickly to the area to be modified.

Thus a block can represent just one paragraph of text, or a structure level with further blocks as its children. Such a "container block" can store its child blocks in a variety of ways. For a page of text, the blocks are stored and sent to the client as an ordered array. In a table container block, the blocks (cells) are stored in a two- dimensional array. As well as embedded tables, this presentation type may be used to represent a spreadsheet. There is also a third type of container block: a "whiteboard". In this case, each block has a rectangle with x, y, width and height, in which its co-ordinates are displayed. This is used for a wrapper for graphics programs such as MS PowerPoint. A presentation slide may be represented as rectangles of fixed position and size, each containing text, an image, an animation, or further blocks. The "whiteboard" container may also be used for concurrent form- designer software. When calling updateBlockTextAndlnfo for a block belonging to a whiteboard container, the block position information sent to the Engine is x, y, width, height, rather than the ID of the previous block. A fourth container type is "newspaper" in which the blocks are stored in an ordered array, but are displayed in a number of columns, with text wrapping from one column to the next. A third block, type (not a container or text) contains embedded objects, e.g. images, as binary data.

Use of XML

Inside the database 12, each document is stored as a tree of XML Elements in the repository 12. The document is also represented as a tree of blocks (Figure 2). The XML elements are mapped to the block tree so that the engine 8 has control over how the document is divided into units for editing.

For example, a paragraph having one bold word in it would be represented using 3 XML elements (one for the emboldened word and one each for the portions of the sentence either side of the emboldened word). Locking at XML element level in this paragraph would be nonsensical, so it is necessary to impose a structure to represent paragraphs, which is a much more intuitive locking unit.

Flowcharts

Figure 14 summarises in flow chart form the overall operation of the system of Figure 1. Initially, a file is stored in blocks (step 30) and then on request, the file is delivered in the form of blocks to a client application 2 (step 32).

The wrapper 4-1 or 4-2 or the new or custom application 2 monitors the user edits (step 34). When it is detected that a change has been made to a particular portion of the document, a request is sent to the engine 8 to lock the block corresponding to the portion of the document which is being edited (step 36).

Once editing of that portion has been completed, for example, by the user moving to a different portion or requesting a save of the document, the file block corresponding to the edited portion is updated (step 38) and sent to the concurrency engine 8.

The concurrency engine 8 performs the necessary conversions to store the updated block as XML elements in the XML repository 12. The engine 8 also delivers the updated block to any other clients 2 or 16 which have the same document open (step 40).

Figure 15 summarises the operation of an application wrapper 4-1 or 4-2. The- wrapper intercepts a file open request (step 42) and receives the file contents as a plurality of blocks from the engine 8 (step 44). The wrapper then interacts with the application to populate an open file with the block contents delivered by the concurrency engine (step 46).

Next the wrapper intercepts user edits (step 48), requests locking of the relevant block (step 50) and sends an updated block to the engine 8 once editing has finished (step 52).

The wrapper also runs a thread which waits for broadcasts of changes made by other connected clients (step 47). As these arrive, the changes are applied to the open document (step 48).

Figure 16 shows the other side of the editing operation i.e. that carried out by the engine 8.

On request, the engine delivers blocks of a document (step 54). The blocks are those shown in Figure 2 and are mapped to XML elements contained in the repository 12. As discussed above, the application 2 or 16 may not request the whole of the document but may instead request particular portions of the document by requesting the children of a particular container block. This is advantageous if the application has a slow network connection to the concurrency engine such as a dialup connection.

Once the application 2 begins to edit a portion of the document, it requests locking of that of the corresponding block within the engine 8 (step 56). The engine 8 then checks whether the relevant block has already been locked (which indicates that it is already being edited). This occurs in step 58. If the block is not locked then the engine 8 locks the block (step 60) to prevent other users editing that portion of the document at the same time. If the block is already locked then an error message is sent back to the application 2 or 16 with information about who is already editing the document (step 62).

Once editing has been completed by the application 2 or 16, the engine 8 receives the updated block (step 63), unlocks the block in the server copy (step 61)and distributes it to other clients who are editing the same document (step 64).

In summary, a "wrapper" client is built around an existing application, such as Microsoft Word, PowerPoint, Excel. The wrapper intercepts keyboard and mouse actions intended for the underlying application and uses them to feed data in and out of the Engine, via the API, instead of a file. The wrapper does not prevent the application from storing some documents in files, in the conventional way (instead of in the Engine), if the user desires,.

A custom client is an application written from scratch solely to work with the Engine. Either a wrapper or custom client could be written to connect to the Engine via Corba, or Java sockets.

As an example, two clients; a Word Wrapper which is a wrapper client which works with Microsoft Word and connects to the Engine via the Corba API and a Java applet client, which allows editing of documents through a web browser and connects to the Engine via the Java sockets API.

All documents start life as an empty document in the database. However, the contents of an existing document stored in a file can be imported into a document in the database. From that point on, the document contents exist as blocks in the i7

database and the original file may be discarded. Both wrapper and custom clients can begin a new document in the Engine, then import an existing file's content into that document. The Word Wrapper user, for example, experiences this import as saving the document into a "file" onto a special drive which is mapped onto the Engine. Typically, an extra menu option is inserted by the Wrapper into Word's menu which says "Concurrency Enable Document" to cause the importation to begin.

Claims

WHAT IS CLAIMED IS

1. A method of sharing file access in a computer network comprising the steps of:-

(a) storing the file contents in the form of a plurality of blocks,

(b) delivering the file to a first client application by delivering the block contents to the client application,

(c) monitoring user editing actions performed on the delivered file in the first client application,

(d) during editing of the delivered file, locking a stored block which corresponds to the portion of the file being edited to prevent other client applications editing the same block, and

(e) updating the locked block with edits performed by the first client application.

2. A method according to claim 1 , including the step of:-

(f) after editing of the locked block is finished, delivering the updated block to other client applications.

3. A method according to claim 1 , wherein the file is stored in a hierarchical arrangement of the blocks.

4. A method according to claim 3, wherein each lowest level block in the arrangement represents a paragraph of a text document.

5. A method according to claim 3, wherein each lowest level block in the arrangement represents a cell of a table or spreadsheet.

6. A method according to claim 3, wherein each lowest level block in the arrangement represents a predetermined area at a predetermined location of a document.

7. A method according to claim 3, wherein each lowest level block in the arrangement represents an object embedded in the file.

8. A method according to claim 1 , wherein a block's contents is delivered to the first client application substantially at the time the user begins editing the portion of the file which corresponds to that block.

9. A method according to claim 1 , wherein the file is represented by XML elements during storage in the server.

10. A method according to claim 1 , wherein the network is a peer-to-peer network.

11. A method according to claim 1, wherein the file is delivered over a dialup or Internet connection.

12. A method of enabling a client application to provide shared file access in a computer network comprising:-

(a) intercepting a file open request in the application,

(b) receiving a file from a server as a plurality of blocks,

(c) opening a file in the application and populating the opened file with the contents of the delivered blocks,

(d) intercepting user editing actions performed in the application,

(e) locking a block in the server which corresponds to a portion of the file being edited by a user via the application,

(f) updating the locked block in the server with the user edits when the user has moved to another portion of the file, and

(g) distributing the updated block to any other client applications which have the same file open.

13. A software wrapper for a client application in a computer network embodying the steps of:-

(a) intercepting a file open request in the application,

(b) receiving a file from a server as a plurality of blocks,

(c) opening a file in the application and populating the opened file with the contents of the delivered blocks, (d) intercepting user editing actions performed in the application, (e) causing the server to lock a block in the server which corresponds to a portion of the file being edited by a user via the application,

(f) sending updates for the locked block to the server which include the user edits when the user has moved to another portion of the file, and (g) receiving updates from the server which represent changes made to the file by other users in communication with the server.

14. A workstation in a computer network operable to:-

(a) receive a file from a server as a plurality of blocks, (b) open a file in a workstation application and to populate the opened file with the contents of the delivered blocks,

(c) record user editing actions performed in the application,

(d) cause the server to lock a block in the server which corresponds to a portion of the file being edited by a user via the application, and (e) send updates for the locked block to the server which include the user edits when the user has moved to another portion of the file, (f) receive updates from the server which represent changes made to the file by other users in communication with the server.

15. A computer program for a. client in a computer network embodying the steps of:-

(a) receiving a file from a server as a plurality of blocks, (b) opening a file in the application and populating the opened file with the contents of the delivered blocks,

(c) recording user editing actions performed in the application,

(d) causing the server to lock a block in the server which corresponds to a portion of the file being edited by a user via the application, and (e) sending updates for the locked block to the server which include the user edits when the user has moved to another portion of the file, (f) receiving updates from the server which represent changes made to the file by other users in communication with the server.

16. A server in a computer network operable to:- (a) deliver a file to a client application as a plurality of blocks,

(b) receive a lock request from a client application,

(c) check that the block requested to be locked is not already locked by another client application and to lock the requested block if it is not already locked,

(d) receive an updated block from the client which requested the block to be locked, and

(e) distribute the updated block to any other client applications which have the same file open.

17. A computer program for a server embodying the steps of

(a) delivering a file to a client application as a plurality of blocks,

(b) receiving a lock request from a client application,

(c) checking that the block requested to be locked is not already locked by another client application and locking the requested block if it is not already locked,

(d) receiving an updated block from the client which requested the block to be locked, and

(e) distributing the updated block to any other client applications which have the same file open.

18. A storage block for containing a portion of a computer file comprising:- (a) an ID field, (b) a contents field, and

(c) a style field.