RE: [Catacomb] external storage of document data
I certainly favor moving towards use of files to hold the contents of WebDAV
resources in Catacomb. From these emails, I'm not understanding the entire
issue space. I think it makes sense to have a face-to-face on this -- are
you free on the 17th or 19th to meet at NASA Ames (UC Ctr, Bldg 555) to
discuss this in depth?
I'm traveling all next week (leaving in about 30 minutes), so we'll need to
resynch after that to set a final date.
I'm certainly OK with bringing in your current code in the interim, though
it sounds like we may want to think a bit about how to structure the
namespace to handle versions and variants. Bryce's ideas sound very good on
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]On
> Behalf Of Chris Knight
> Sent: Friday, February 28, 2003 11:11 AM
> To: firstname.lastname@example.org
> Subject: [Catacomb] external storage of document data
> All, we've implemented external storage of file contents for Catacomb
> and I'd like to discuss merging it back into the main Catacomb release.
> It's fairly straightforward, however there is one (philosophical?)
> decision to make. I'd like to hear your opinions and see if this
> activity is already underway by someone else.
> Should the names/organization in the filesystem mirror the structure in
> Catacomb? Another option is files can be stored in a hashed directory
> structure based on the document id.
> Advantages of mirroring the structure in the fs:
> * easy to understand
> * can be interacted with outside of DAV
> * performance of containers with many (thousands) resources and for
> very deep container hierarchies
> * hard to divide between filesystems (a useful operation as the DAV
> repository grows)
> * requires a filesystem operation for MOVE operations
> * how to store multiple versions of a document?
> * changes outside of the DAV interface should be mirrored back into DAV
> * limited to the character set restrictions of the fs (or need to store
> the filesystem name of the file)
> FYI, I used to work on a web-based document management system and we
> moved from mirroring the structure to using a hash structure to resolve
> problems that occurred when people did many move operations. Conversely,
> our Catacomb server we are working with here at NASA mirrors the
> structure into the filesystem (and I may work on a system to mirror back
> into Catacomb when changes are performed on the fs.)
> Catacomb mailing list