After a bit of thought, I've got a few more points about The XML Object File System idea.
Minor point - the data of a file/object would be stored in an attribute named "default-data" or "data" or maybe even "" (that's the one old software gets when you don't specify an attribute when opening an object). You'd get a file handle to an attribute to be able to read and write its value. When all handles to an attribute are closed, the index gets updated with the new value (if it's an indexed attribute). Possibly it would have to be removed from the index when the handle is opened (otherwise you'd have to keep around a copy of the old attribute value to know what to delete from the index). Hans Reiser <[EMAIL PROTECTED]> wrote on Sat, 05 Jan 2002 03:44:22 +0300: > Miguel, do you agree that if and only if one makes directories > and files functional enough, then it becomes a cleaner design > to have just files and directories? and other people also commented on liking just files and directories. I can see how the object system could be expressed as just files and directories: * Each object becomes a directory. The name is the object's name, probably use the Human readable one to make manual hacking easier. * An object inside another object becomes a subdirectory. * Each attribute becomes a file in the object directory, name being the attribute name and contents being the value of the attribute. Still, you need an extra type encoding somewhere to say that the attribute is a string, or number, or link reference or other simple type. Encode the primitive type as the first byte in the contents if there's no better way. * There needs to be a global directory of all objects, for finding a particular object when given the ObjectID. It has the unique ObjectID as the name and the link points to the object directory. Either symbolic links or hard links could be used. Another way would be needed for finding remote objects, perhaps URLs instead of ObjectIDs? * The index directories work similarly. For indexed attribute named "X", there is a global index directory named "X" which contains an entry named with the attribute's value and pointing to the object directory that contains the attribute. The index directory has to allow multiple entries with the same name (since several objects could have attributes with the same value). * Notification of changes to files/directories get mapped to notification of changes to objects. The next question is then should the objects be done as part of the file system level or as a new object system level? I think it would be easier to write the object level initially as a system library and have new software go through it instead of the normal file system API. Or have it as a file system with extra ioctl operations for the new features, that way old code works with the "default-data" attribute. When viewing an existing old style file system through the object system, old style items show up as fake object - "/etc" is an object of type object-container with attribute "fstab" having a value of simple-type binary with whatever's in that file. If they add an icon to "/etc", a new file called "Icon" appears with the icon data as its contents (or maybe an Icon object is used which contains several different graphic objects, one for each resolution - the icon is then a directory containing a subdirectory "Icon32.png" which contains the PNG image in a file called "default-data" and has more files such as "width" containing 32 as a 4 byte binary number). Locking objects? Corresponds to locking directories. Locking attributes corresponds to locking files. A handle to the object corresponds to a handle to the object directory. The object system will probably use its own handles, but include the corresponding file system handle inside. Change notification? The underlying simple file system notifies the object system of changes to the attributes (attribute file changed) or addition of new attributes (object directory changed) or changes to the index (index directory changed). The object system would probably also update the index directory and global ObjectID directory rather than having the file system do it. Networking? Either share at the file system level or share at the object system level? If file system notifications work across the network, and locking works too, then you should be able to get by with just sharing at the file system level. Indexing queries? The object system just searches through the index directories. Live queries are handled by monitoring change notification messages from the index directories (added/removed objects are run through the user's query filter and if they match, an object added/removed notification is sent to the user). A file system which could support lots of small files (most of them with the same file name too) would be ideal. Wonder where you can get one of those :-). But it still needs change notification, and sorted directories (a way of quickly finding entries in a specified range without having to start at the beginning). Plus the usual symbolic links (or hard links), long file names, maybe an extra byte or two for attribute types, and networkability. - Alex
