David Masover wrote on Thu, 18 Mar 2004 17:04:30 -0600: > | David> What about a reiser4 plugin? > | > | I would think that would count as being in the filesystem level. > > Yet it doesn't involve writing a *new* filesystem, which is I think what > was being suggested? Alexander?
I was concerned that new features should also be available to all programs, preferably through the existing file system API (open, close, readdir, etc), rather than having a separate API layer (adding a few functions is OK). I don't care if it's a new file system under the hood, or enhancements to an existing one; the important thing is that all programs be able to use it easily. For example, you could add a mkquery() to the usual API to make a virtual directory that contains the results of a query (query patterns specified as an argument to mkquery). I'd be satisfied if other software can open that virtual directory just like a regular one, and use readdir on it. Of course, creating a file in the virtual directory would return an error code (or you could have that operation automagically add attributes to the new file which would make it satisfy the query). The general idea is to avoid having multiple application programming interfaces. Keep it unified and you get more power through synergy. Such as being able to use grep or ffmpeg on all files in a virtual query results directory. - Alex P.S. Normally I wouldn't use "synergy", but it makes sense here.
