Hans Reiser wrote:
What I am saying is that each of the N permutations required to
transform a file into an extended attribute should be separately
selectable. Theory guys would call this orthogonalizing the primitives.
(I am a theory guy.;-) ).
Applying such rigor in the architecture design phase is probably a good
idea. Doing it at application run time is not so clear to me.
If you think of files and EAs as apples and oranges, knowing the minimal
set of orthogonal steps to turn an apple into an orange is good when
designing, but I hesitate to burden an app with having to select the
"skin-color" characteristic separately from the "ascorbic acid content"
characteristic. IMHO, files and EAs are "package deals" where we have
chosen a different set of characteristics for each, ones that we believe
will be useful to an app.
At bottom, a file holds an uninterpreted data stream. You have to ask
yourself whether you want that to change or not. If not, then you
build any additional functionality in selectable layers on top of the
filesystem, not in it. If you do want it to change, then you are
headed down the path of pulling a database into the filesystem. Come
to think of it, I believe that someone is already doing that. :-)
Having an interface such that an app can ask for
where each of the "F_*" options are orthogonal and ask the filesystem to
layer in a different "filter" between the raw data and the app, or to
change the access characteristics (eg: block alignment, non-buffered,
etc), sounds overly complex. I believe that this would be better done
by explicitly stacking filesystems in a per-process namespace.
#define PIZZA F_OLIVES|F_PEPPERONI|F_ANCHOVIES|F_PINEAPPLE
#define EDIBLE_PIZZA F_OLIVES|F_PEPPERONI|F_PINEAPPLE
Your way allows for PIZZA but not EDIBLE_PIZZA to be selected by users.
are easy to specify.
You cannot know in advance what a user will consider to be EDIBLE_PIZZA.
Not allowing choice is for, umh, better I not say what OS likes to
Ok, so I understand that what I am advocating is a lot of work, and a
much harder path to take,
and I understand why you feel you have enough work, and I think we can
both respect each
other for our positions.
I'll try to convince you again when I have working code that isn't
monstrous code, but allows
users full choice, ok?