Date: Wed, 5 Jun 1996 17:46:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: jehamby@lightside.com, jfieber@indiana.edu, bostic@bsdi.com, current@freebsd.org, jhs@freebsd.org, terry@lambert.org Subject: Re: editors Message-ID: <199606060046.RAA00195@phaeton.artisoft.com> In-Reply-To: <28584.834019322@time.cdrom.com> from "Jordan K. Hubbard" at Jun 5, 96 05:02:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Hmmmm. I see Terry on the Cc list. Might as well go for broke.. :-) > > What would be really neat, mind you, would be to be able to view a > filesystem as a set of objects with property lists, sets of objects > being represented by "views" (which would, of course, themselves be > objects). Using some sort of query API, you could create new view > objects to give your objects some illusion of an organizational model > (e.g. the existing hierarchichal one or something even more > outlandish). Sort of a poor man's relational database at the > filesystem level. > > Then all the rest would be trivial, the implementation of which would > be left as an exercise to the reader. :-) Actually, a minor modification of the nullfs could result in a umsdosfs (assuming the layering call ordering is fixed and the VFS is called for veto rather than implementation for locking, etc.), so there's no reason to believe that you couldn't stick a disk quota interface, or any other type of attribution in there as well. This is actually one of the design goals of the stacking architecture mentioned in John's thesis, and one of the main reasons I go on and on about the Heidemann framework having been "pounded into 4.4" by the CSRG folks (who were working on a timetable in the face of legal adversity -- no blame to them). It's also what I mean when I talk about "layering fixes"... enabling this type of stacking usage (try implementing a quota layer in the current code and watch the VOP_LOCK code go to hell in a handbasket). An attributed FS is definitely one of the goals I have; I just finished sending an email to some other FS hackers in an ongoing discussion of "how to implement a generic bottom-end block interface with transactioning" using the soft updates work. This toenails nicely into the idea of a generic addressable block store in a flat block name space, on top of which you implement attribution services for attributes like, oh, say, names and directory hierarchies. 8-). I think this is the direction we eventually want to pursue to get the most flexible framework for doing the sort of UI things you are talking about here (icon binding, etc.). There's also the FS event model, which lends itself to soft update representation as well... you need something like that to be able to say "I'm a GUI directory browser; tell me when the directory I'm displaying changes so I can update the screen for the user immediately instead of after some lame timeout, like Windows or Mac's or UnixWare boxes". 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606060046.RAA00195>