11.8 Multiple Checkouts with Working Resources

The fork and merge features we've just seen allow multiple users to work on files, but they don't allow multiple users to check out files simultaneously. With all the features described up to this point, Bob can create a fork by checking out a version that already has a successor. However, Bob can't check out his version while Alice has her version already checked out he has to wait for Alice to check in first. In multiuser versioning systems, this isn't always acceptable.

If Alice already has the document checked out and is editing it in place, Bob needs to be able to check out his file to a different location and edit the file there. DeltaV provides the working resource feature to allow this functionality. The working resource has its own URL, so Bob can PUT and PROPPATCH in that location, separate from Alice's changes to the VCR location.

11.8.1 Creating Working Resources

A working resource is created with a CHECKOUT request. To create a working resource based on the target version, the client can send a CHECKOUT request to the VCR with an XML request body. The XML contains the apply-to-version element inside a checkout root element. This request creates a working resource with the auto-update property pointing to the VCR. This means that when the working resource is checked in and a new version is created, the server will automatically update the VCR's checked-in property to point to the new version (see Listing 11-9).

Listing 11-9 CHECKOUT of a VCR to create a working resource.
 CHECKOUT /docs/index.html HTTP/1.1 Host: www.example.com Content-Type: text/xml; charset="utf-8" Content-Length: 1234 graphics/enter.gif <?xml version="1.0" encoding="utf-8" ?> <D:checkout xmlns:D="DAV:">    <D:apply-to-version/> </D:checkout> HTTP/1.1 201 Created Location: http://www.example.com/wr/docs/index1.html graphics/enter.gif 

In response to the CHECKOUT request, the working resource is created with a URL chosen by the server. Working resources could theoretically appear in some regular collection in the repository, but they are more likely to appear in some reserved namespace. There is no way to browse for working resources.

Whenever a VCR is checked out with apply-to-version, the server must perform these steps:

  1. If the target version has a successor, make sure it allows checkout-fork.

  2. Create a working resource where the checked-out property points to the target version. Initialize the contents and dead properties of the working resource from the contents and dead properties of the version.

  3. Set a live property called auto-update on the working resource. This property points to the VCR, which will be automatically updated when the working resource is checked in.

  4. Mark the version checked out by adding the working resource URL to the version's checkout-set property.

  5. Respond to the client with a 201 Created code, including a Location header with the URL of the working resource.

Although Figure 11-10 suggests that the working resource exists off in space, that's not necessarily true. A DeltaV server could even put the working resource inside the same collection as the VCR through which it was created.

Figure 11-10. Working resource relationships.

graphics/11fig10.jpg

A working resource does not have a new resourcetype value. It's not a new kind of resource, it's just a resource that happens to be checked out. If the client has a URL to some resource and needs to know if it's a working resource, the client must examine other properties. A working resource is required to have all the same properties as a regular checked-out resource. The auto-update property is unique to a working resource, but it doesn't always exist, so that's not a reliable property to look for. Instead, a client can try to look at the supported-method-set property. If the resource supports UNCHECKOUT, it can't be a working resource, because only a checked-out VCR supports UNCHECKOUT.

Working Resources without Simultaneous Checkouts

Some pre-DeltaV versioning servers effectively have working resources (edits are made in a server location not normally visible to other users) but do not allow simultaneous checkouts. In these servers, a checkout acts as if it locks the resource so it can't be checked out by other clients. It's not clear whether this model can be implemented in a DeltaV server that must interoperate well with standard DeltaV clients.


11.8.2 Editing a Working Resource

When a client checks out to a working resource, write operations are sent to the working resource, rather than the VCR that is not checked out. While the working resource exists, it is a complete stand-alone resource. For example, it may be locked or unlocked independently of the VCR it was created from.

graphics/roadt_icon.jpg

A GET operation on the working resource will return the latest changes to that resource, whereas a GET operation on the checked-in VCR will still return the contents and dead properties of its target version. If any other users have permission to view the working resource, these users can see the results of any write operation to the working resource.

DeltaV does not specify whether other users can view or edit working resources. Certainly the user creating the working resource ought to have permission to view and edit it. Perhaps the working resource should be limited so that only that user can view and edit it, or perhaps the working resource should inherit its permissions from the permissions of some other appropriate resource such as the VHR. If the server supports the WebDAV Access Control specification, it may even be possible to change permissions on the working resource and explicitly allow new principals to edit it.

graphics/roadt_icon.jpg

Before checking in, the client should set the comment property and make sure the predecessor-set value is appropriate, considering whether the checkin will create a fork and whether the server will allow the fork to be created. (Check the checkin-fork property on the checked-out version.)

11.8.3 CHECKIN a Working Resource

When a working resource is checked in, the state of the working resource is used to create a new version and the working resource is deleted. Since the working resource is deleted when it is checked in, a working resource never exists in the checked-in state.

For interest's sake, we'll assume that the predecessor-set of the working resource names a version that already has a successor, so this checkin will create a fork. The client has checked the value of checkin-fork on the version that was checked out, and its value is discouraged. However, the user has confirmed that creating a fork is the intended outcome of this checkin, so the client includes fork-ok in the CHECKIN body (see Listing 11-10).

Listing 11-10 CHECKIN working resource.
 CHECKIN /wr/docs/index1.html HTTP.1.1 Host: www.example.com Content-Type: text/xml; charset="utf-8" Content-Length: 1234 graphics/enter.gif <?xml version="1.0" encoding="utf-8" ?> <D:checkin xmlns:D="DAV:">    <D:fork-ok/> </D:checkin> HTTP/1.1 201 Created Location: http://www.example.com/his/vers1/35.html graphics/enter.gif GET /wr/docs/index1.html HTTP.1.1 Host: www.example.com graphics/enter.gif HTTP/1.1 404 Not Found graphics/enter.gif 

This interaction shows a checkin to a working resource, which creates a new version, and the new version's URL is returned. The checkin was intended to create a fork, and it may have; the server does not specify whether a fork has been created in the response. The GET request and 404 Not Found response are shown to illustrate that the server has cleaned up the working resource.

When the working resource is checked in, the server performs the following steps:

  1. Examine the successor-set property of the checked-out version to see if a fork will be created. Make sure the checkin-fork property of the checked-out version allows a fork to be created.

  2. If the checkin is allowed to proceed, create a new version with the contents and dead properties of the working resource, and copy the value of predecessor-set from the working resource.

  3. On the checked-out version, change the successor-set property to include the URL of the new version. Remove the live property checked-out.

  4. If the auto-update property contains a VCR URL, change the checked-in property of that VCR to contain the URL of the new version (and make sure its contents and dead properties are the same as those of the new version).

  5. Delete the working resource. Respond to the client with the Location header and the URL of the newly created version (see Figure 11-11).

    Figure 11-11. CHECKIN working resource deletes working resource.

    graphics/11fig11.jpg

The client may not use UNCHECKOUT with a working resource but may DELETE a working resource. This operation cancels the changes and deletes the working resource. The server cleans up the version that was checked out, to reset to its previous state (no checked-out property).

If the working resource is never checked in and never deleted, the working resource exists indefinitely. DeltaV has no provision for a working resource to expire. The version would also remain checked out, which may prevent other checkouts if checkout-fork prevents forks.

11.8.4 Working Resources Create Forks

Working resources make it very easy to create forks, accidentally or intentionally. Here are some of the ways forks can be created:

  • Check out a version that already has a successor. Leave the predecessor-set of the working resource alone. Check in.

  • Check out a version that does not have a successor, but change the predecessor-set of the working resource so that it points to a version that does have a successor. Check in.

  • Check out a version that already is checked out. If both are checked in (without altering the predecessor-set), the two checkins will create new versions with the same predecessor.

graphics/bomb_icon.jpg

There is no way for the client to ensure it doesn't create a fork. The client can check out a version without a successor, edit the working resource, and just before checking in, make sure that the checked-out version still does not have a successor. Then, just before checking in, another user could update the version history such that the checked-out version now has a successor. There is no way for the client to indicate to the server that it does not want to create a fork on checkin. There is also no way for for the client to prevent other checkins for a time. The client could lock the VCR to try to protect it from being updated; however, it may not be possible to prevent working resources from being created, and as shown in the next chapter, there may even be multiple VCRs.

11.8.5 Checking Out Other Versions

Other versions, not just the current target version, can be checked out too. A CHECKOUT request addressed to a version URL also creates a working resource (however, the auto-update property must start out empty). This can be a useful shortcut if a user wants to work from the content of a specific version other than the target version. The working resource is initialized with the requested version's content, not the target version's content (see Listing 11-11).

Listing 11-11 CHECKOUT of a version creates a working resource.
 CHECKOUT /his/vers1/32.html HTTP/1.1 Host: www.example.com graphics/enter.gif HTTP/1.1 201 Created Location: http://www.example.com/wr/docs/index2.html graphics/enter.gif 

Listing 11-11 shows a CHECKOUT of a specific version and the server's response indicating that a working resource was created. The server must perform these steps:

  1. If the requested version has a successor, make sure the value of checkout-fork allows a fork to be created.

  2. Create a working resource where the checked-out property points to the target version. Initialize the contents and dead properties of the working resource from the contents and dead properties of the version. Add a checked-out property that points to the requested version.

  3. Mark the version checked out by adding the working resource URL to the version's checkout-set property.

  4. Respond to the client with a 201 Created code, including a Location header with the URL of the working resource.

Note that the auto-update property is not added to the working resource, although it was in the steps outlined in Section 11.8.1.

The server must perform the same steps on checkin outlined in Section 11.8.3, except that if the auto-update property is still absent, there is no need to update any VCR's checked-in property.



WebDAV. Next Generation Collaborative Web Authoring
WebDAV. Next Generation Collaborative Web Authoring
ISBN: 130652083
EAN: N/A
Year: 2003
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net