NEWS/BackendStorage

The need is for a storage system that is capable of storing the ACL information about a page, capable of being flexible with names and subpages, and is within any limitations of the storage system. (ie, unix/doc/etc directory tree structure for file layout. This assumption is made because it's well understood, suitably flexible, matches the structure of normal websites which exist on such trees, and means the current preffered backend (CVS) suits perfectly). It should be compatible with traditional (unix-like) file-tree structure, though by no means is this a requirement of the backend storage method.

So, Pages are stored as a directory (named as whatever the pagename is), with two files - one named '_markup' for the page contents, and one named '_acl' for acl data. Subpages are subdirectories, and are not allowed to begin with an underscore. This way the tree is selfcontained/integrated, flexible, obvious, and also allows for future expansion (ie, further _name special files or directories. (_blog for example)

Note that alternate storage systems do not have to maintain this structure - this is just the "worst case scenario" (ie, flat filesystem) storage system. If we use subversion, for example, acl data may be kept as a subversion file property (which can hold arbitrary name=value pairs, is correctly versioned, etc. acl data may yet end up just using the subversion native acl method... I'll know when I find out if subversion is capable of it... ;)

Are page names case sensitive? (ie, is "WeBlink" the same or a different page to "WebLink"? A: If the storage system sees them as the same (eg: flat files on HFS+, NTFS, FAT32), then those pages WILL be the same. If the storage system sees them as seperate (most/all unix and clone filesystem, and sql storage setup, etc), then NEWS will see them as seperate. (though if wanted, an option to squash case could certainly be made available)