There's an implicit assumption: that you use the albod to store attributes
of a file. If you use that albod to store just a collection of related
files, this constraint shouldn't matter, because a) the user or the
application needs to know a little about the albod's inner structure (or
they wouldn't know in the first place to expect to find a viewable image),
and b) you can always access wherever/albod/foo.gif, or maybe, if you
want to be really sophisticated, wherever/albod/link-to-viewable-image.
Another tricky issue, although it should be possible to overcome it:
consistency when files are changing and the albod-unaware reader seeks
(e.g. to sequentially read the same data several times to try different
compression algorithms, or maybe to implement a hyper-efficient
transport protocol without buffers ;-).
An albod-unaware application working on albod components my have write
semantics that allow sequential retrieval of each file without being
disturbed by writes, but this may not be the case if your accesses
span multiple files. (E.g. consider file growth.)
> Rather, this was intended to serve as some food for thought, and a proof
> by example there is a way to do this in user-mode, without requiring
> Linux-specific filesystem hacks and extensions.
If something like this is ever implemented, then a design that allows to
do it in user space is certainly a wise choice, even if it actually gets
implemented in the kernel.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/