On 2007-02-28, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Feb 2007 10:20:33 +0000 (UTC) Tuomo Valkonen <[EMAIL PROTECTED]>
> wrote:
>
> TV> In fact, for tab-completion to work nicely, most tags should
> TV> perhaps be listed. Ideally the application in question would
> TV> do the pruning/clustering as suited to the task at hand, but
> TV> in a FUSE plugin for applications (mostly) unaware of SetFS,
> TV> we do not have the luxury of that. But for 'ls' output the whole
> TV> list can be unusably long.
>
> Just like `ls', I don't think you should filter out results, just
> write a filter tool or an option to make the list usable.
It's not really filtering out anything, just producing a dynamic
hierarchy for the *nix tools that have been written for hierarchic
file systems. I think the default behaviour should be adjusted for
them, not tools aware of SetFS, which can, of course, use other
methods.
If a simple list of tags is sufficient, then #options in the path
could do it, but if the real search results are wanted, we don't
want to cram them down through `readdir`. (I'm thinking of a FUSE
plugin here constantly!) Therefore some other communication method
is needed. One very simple option is a special read-only file with
an additional #listing or some such element in the path. So if our
file system had the files foo/bar, foo/bar/baz, and foo/quk, then
the read-only file foo/#listing could, for example, have the contents
bar
bar/baz
quk
(You don't want to pass that slash down readdir!) Some additional
information might also be passed in this file (or a file with
additional #options), if the FS can do it more efficiently during
the search than it would be for the application to obtain that
information for each file separately.
(If we pass the set identifier down the file instead of an internal
numeric object identifier -- inode number, if you will -- the inode
will probably need to be accessed during the search for each of the
results, and therefore additional information is quickly available
during the search. Contrast this with traditional unix file systems,
like ext3, where `echo /usr/bin/*` is immediate, while `ls /usr/bin/*`
is not quite as fast. This is because the latter has to read the inode
`stat`, whereas the former doesn't. #listing could, of course, just
list inode numbers, and another channel be provided for converting
inode numbers to tag sets or other information. I'm not sure which
behaviour is preferrable, although I do think exposing inode numbers
is a bit ugly.)
--
Tuomo
