Document Store is structured as a system of distinct objects, designed to be distributed (eg not on the same system) and communicate through an RPC mechanism such as CORBA. Each of these objects performs a set of specific operations in relation to the Document Store, and can be implemented in any way that would allow them to answer to those operations. Document Store is made up of three major sub-systems, which make up the core of the Document Store functionality: StoreFront, MetaStore and PhyStore. Layered on this core of functionality, there are additional systems: The Library and SuperStore. These provide card catalog and multiplexing functionality, respectively, and are described in . FIXME: provide an ASCII digram The PhyStore component is an abstract filesystem interface. It provides a simple interface to the blocks of bytes which are associated with an identifier, which are accessed in a transaction-based mode (either a read or a write of the full data). Phystore stores the body portion of the documents, and can be used to make backups of the meta-data stored in the Metastore. Phystore has the following interface definition: PhyStore // create a new storage area phystore-handleNew // store some chars in a storage area booleanPutphystore-handleHandlecharacter-dataData // get some chars from a storage area character-dataGetphystore-handleHandle // destroy a storage area booleanFreephystore-handleHandle // get the length of a storage area numericLengthphystore-handleHandle The phystore-handle type may be numeric or an oblique data structure that represents the particular resource; it can be thought of as an object reference to a storage area within the Phystore. It is probably best if this handle is savable so that storage areas may be accessed without keeping the particular reference around (in other words, so that it can be stored in a database elsewhere). The character-data type may be thought of as a char[] with associated length and possibly associated hash sum. The MetaStore component is where the system stores the meta-data and atoms associated with the documents. See for further information about the particulars of the tables that would be stored in this subsystem, suffice it to say that this could be implemented using a standard RDBMS, such as those provided as an abstract through GComm. The Metastore can use the PhyStore as a backing or as a backup for security. The MetaStore has the following interface definition: MetaStore FIXME: define the methods for this FIXME: proposed SQL tables for document here? or in the documents chapter? Maybe use XML DDL instead of a native format. The Storefront component provides the interface which, generally speaking, "client" objects and layers built on top of Document Store Core speak to. It provides interfaces to store, manipulate and access documents and sub-documents within the rules of the Document Store. It does not provide the ability to search or locate documents by anything other than their identifiers (this functionality is provided by applications build on Document Store Core, such as The Library as described in ). The StoreFront has the following interface: StoreFront //## Document Creation // create a new document document-identifierNew // create a new sub-document subdocument-identifierInstantiatedocument-identifierDocument // copy an existing sub-document, adding it to the document subdocument-identifierDuplicatesubdocument-identifierSubDocument //## Document Storage // associate character data with a sub-document booleanPutBodyxml-character-dataBody // update or associate atoms with the document booleanPutAtomxml-character-dataAtoms // replace existing subdocument data with new subdocument data booleanPutAllxml-character-dataAllSubDocument // # As above except that identifiers are passed on the call rather than in the XML // associate character data with a sub-document booleanIPutBodysubdocument-identifierSubDocumentxml-character-dataBody // update or associate atoms with the document booleanIPutAtomatom-itentifierAtomxml-character-dataAtoms // replace existing subdocument data with new subdocument data booleanIPutAllsubdocument-identifierSubDocumentxml-character-dataAllSubDocument //## Accessing Documents // get sub-document xml-character-dataGetsubdocument-identifierSubDocument // get all sub-documents of a document xml-character-dataGetAlldocument-identifierDocument // get the metadata from a sub-document xml-character-dataGetMetasubdocument-identifierSubDocument // get an atom from a sub-document xml-character-dataGetAtomatom-identifierAtom // get all atoms from a sub-document xml-character-dataGetAllAtomssubdocument-identifierSubDocument // get the identifier for the newest sub-document (by time of update) subdocument-identifierGetNewestdocument-identifierDocument // get the identifier for the oldest sub-document (by time of update) subdocument-identifierGetOldestdocument-identifierDocument // get a list of all sub-documents subdocument-id-listGetListdocument-identifierDocument //## Changing Document State // commit a sub-document (prevent further updates) booleanCommitsubdocument-identifierSubDocument // destroy an unlocked/uncommited sub-document booleanDestroysubdocument-identifierSubDocument This is a large interface, but fairly straight-forward. The various identifiers need to be savable, and could be implimented as simple aggregates of numbers--a document identifier could be a single number, a sub-document identifier could be an array of two numbers (a document identifier in the first, and a sub-document identifier in the second), an atom identifier an array of three numbers (the frist two a sub-document identifier and the third an atom identifier). The xml-character-data type is indended to carry XML-encoded documents in the format described in ; this format allows certain parts of the documents and sub-documents to be passed (including specific atoms) and identified. The alternate interfaces (prefixed with I) that include the document identifiers allow for simpler interfacing--no identifiers need appear in the XML passed to these interfaces. It should be reiterated that any updating operation on a subdocument that has been commited will fail with a false value (possibly raising an exception if the environment supports it); this is the standard semantics of commited/uncommited as described in