The Decaffeinated Alternative

If we had the luxury of designing Patron for a closed system (one in which no one ever copies files off the system), we would save an enormous amount of trouble by writing all our data structures into various files in a directory tree:

• The "document" would be a base directory, named as any other document would be, and all the information in that directory would be considered part of the document. In this directory are files that contain the "file header" information: the count of pages, the name (subdirectory of the first page), and printer configuration.
• Each page is itself a subdirectory named PAGEnnnn.nnn (under the "document" directory), which would allow up to 10 million pages per document. No problem. Each page directory contains files with the page information, such as the names of tenants. (This eliminates the need to manage the offsets to them.)
• Each tenant is itself a subdirectory named TENnnnnn.nnn (100 million per page), which allows the tenant to create any files it wants and to store any information within that directory. This would even make it easy for other applications to manage the tenants because those other applications could easily write information into this directory.

Overall, this promising scheme would look like the layout shown in Figure 7-5. To add a page or a tenant, we create another subdirectory off the appropriate directory and write its specific files. Deleting a page or a tenant is as simple as deleting a directory. In both cases, we let the file system worry about free space, garbage collection, and defragmentation. We inherently let the end users control overall performance by their choice of underlying file system and defragmentation tools. More power to them!

Figure 7-5.

A possible Patron storage scheme using directories.

And, even better, incremental access, for saving and loading information, is always the primary mode of operation. Changing the contents of one tenant means rewriting a part of a single file without bothering anything else in the entire "document." Reading in the contents of a tenant, or retrieving the count of pages in the document, requires us to access only a few relevant files in the right place in the hierarchy, all of which can be done very fast. Overall, this incremental capability means that we probably never have to rewrite the entire file, even to change its name. (We can just rename the base directory.)

But there is a snag: someone kindly points out that this design assumes a closed system, a far cry from anything our customers are using. Reality check! End users will despise having the information for a single "document," as they understand it, be spread around a bunch of directories, meaning that they have to do complicated backup procedures to simply copy a document to a network location or send it to a colleague in a piece of e-mail. We're reminded that an application implemented this way will sell about as well as Double Tall Macho Grande Decaffeinated Latte in downtown Seattle. That is, not at all. So now what?