NEWS/BackendStorage
(Moved from /Implementation) |
m (3 revision(s)) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
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. |
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. 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) |
+ | 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) |
| − | ''I thought we decided that a Page was a directory with three items: a file called "_markup", a file called "_acl", and each sub-page as a sub-directory (and the assumption that wiki page names cannot start with an underscore. -- [[Screwtape|st]]'' |
+ | 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... ;) |
| − | This scheme is nicely integrated, keeps acl and markup data in seperate locations, but integrated in the same tree. (as opposed to being in the same file, or wholly independant trees. It also allows the pagenames to be anything at all without restriction. |
+ | 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) |
Latest revision as of 02:04, 25 October 2007
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)
