# Jigsaw 2.0 Internal design

### The new Resource

In the previous version of Jigsaw (1.0), the inheritance tree of Resources was:

All the basic Resources, such as FileResource and DirectoryResource, were heavily linked to HTTP as all the resources served were extensions protocols that are not HTTP-related, we propose this new version of the Resource:

Where (1) and (2) are ResourceFrames. A Resource is now a very basic thing, containing only information that the raw Resource can provide (e.g., for a file, the size, last modification date, creation date if available, etc.), then, attached to that Resource, we find the ResourceFrames that extend Resource (they are handled the same way) and contain information about the Resource they are attached to.

To serve a resource using a protocol -- for instance, HTTP -- the Resource will have a protocol ResourceFrame, HTTPFrame, that contains all the information needed to serve this Resource using HTTP. This frame is like the old version of HTTPResource, but it contains more information than the previous version.

The filters are now divided in two categories: the filters on the Resource and the filters on the protocol Frames. The usual filtering scheme used in the previous version of Jigsaw is still valid. The main difference is that filter sare no longer attached to the Resource itself but to its protocol frame. ResourceFrames can also have frames.

Other kind of frames can be attached, like RDF frame for metadata, PICS frame to rate this resource, etc...

The new inheritance tree is:

more complex, but more flexible than the previous version.

### The new ResourceStoreManager

In order to share all the Resources amongst different servers efficiently, we created a new central ResourceStoreManager. In the previous version the Resources were handled by other Resources. For example, the FileResource was handled by its DirectoryResource. This induced a number of bugs and was not very well-adapted to the new way of sharing Resources. There is now only one manager for the server handler so that each server will talk to this sole manager.

This RSM contains a hashtable associating a key (unique indentifier of a ResourceContainer) and a StoreEntry. The StoreEntry contains the store of the resource sons and a hashtable associating the identifier of the sons of the resource and the ResourceReference of those resources.

The ResourceReference is used like this:

      ResourceReference rr;
      ....
      try {
         Resource res = rr.lock();
         ....
      } catch (InvalidResourceException ex) {
        /* InvalidResource means that the resource has been deleted */
         ....
      } finally {
        rr.unlock();
      }
      ...

If the resource has been garbage-collected, the rr.lock() will load it again, and during the lock, it is guaranteed that the resource won't be deleted, unloaded or modified by someone else. This allows safe concurrent modification access to this resource.

Now the container is no longer responsible for the management of its son; it only has a key to the StoreEntry, which contains its sons. To get its own store, the resource has to ask its parent for the StoreEntry that contains it.

Jigsaw Team

$Id: design.html,v 1.12 1998/07/09 13:18:21 benoit Exp $

Copyright © 1997 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.