Ralph wrote: > Edward Shishkin wrote: > >> Be careful with the notion of plugin: in reiser4 this is only >> to manage low-level data storage infrastructure.. That said, >> first, you should decide what (useful!) feature related to >> (low-level!) data storage do you want to implement, then think >> how to implement it in the plugin categories. Most likely you'll >> need to add new plugin(s) of existing or (unlikely) new interface. >> For example, in order to support (meta)data checksums you'll need >> a new node format, and, hence, new node plugin (the NODE interface >> already exists). >> All other "plugins" should go to vfs, or to various stackable >> (distributed) filesystems. >> > > (meta)data like xattr low-level? > Sure. It is supposed to be stored on disk. > >> in reiser4 this is only to manage low-level data storage infrastructure >> > ... at this stage of reiser4 is low-level, because the main effort is inclusion in mainline kernel, I thought... > > What if you want to write a storage backend for postgresql where content shall be readable per file syntax: > cat ./database/contacts/names/name/address/streetname > (Sure, you can have a postgresql service that exports streetnames....) ?? > > Look at: H. Reiser writes: > "I am going to do the enhanced semantics first" > ( http://marc.info/?l=reiserfs-devel&m=115363946628080&w=2 ) > > That is not so low-level ? I am not a specialist in enhanced semantics. There is a lot of problems on the storage level ;) Edward. -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
