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? > 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 ? But, as Chistian Stroetmann just said in this thread: Namesys philosophy is different than actual reiser4 aimings? Ralph -- 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
