From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 16 Aug 2012 21:48:45 +0200 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20120816194845.GA1519@polynum.com> References: <20120803171847.GA2720@polynum.com> <501D12A1.1060906@yahoo.fr> <20120804152016.GB433@polynum.com> <20120805173639.GA395@polynum.com> <20120815173327.GA424@polynum.com> <20120815200949.4628BB85B@mail.bitblocks.com> <20120815212734.GA1190@polynum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Multi-dimensional filesystem Topicbox-Message-UUID: aa5220bc-ead7-11e9-9d60-3106f5b1d025 On Thu, Aug 16, 2012 at 08:02:52PM +0300, Eugene Gorodinsky wrote: > > > > First one, related to what I was wandering about, is mathematical > > definitions and relationships. Take the picture of the first volume o= f > > van der Waerden's Albebra (I have the german edition and will keep th= e > > german words). We speak about links between notions presented in a > > linear order: the order of the chapters: > > > > Galois theory chapter is the descendant of concepts from > > Vektorr=E4ume, Fortsetzung der Gruppentheorie and K=F6rpertheorie cha= pters; > > Vektorr=E4ume and Gruppentheory being siblings ("children" of Ringe u= nd > > K=F6rper) while K=F6rpertheorie is a grand-child of Vektorr=E4ume. > > > > Example of multiple parents, and not at the same level. > > > > This seems to be possible to recreate with befs, but I have to say: t= his > particular problem is too specific to be solved with something like a > filesystem. One should write a fileserver only when that would allow th= e > user to use multiple familiar tools to work on the task. With your exam= ple > it looks like the only thing the user would need here is the list of > related topics along with the description of their relationship so that= a > related topic could be chosen and read. You can use a relational databa= se > for storage of the content along with the list of related topics and a > program that can browse that database and follow the links. A user woul= d > never even think about doing something like 'cp ./Galors theory/parents > ./Galors theory/children, even though the approach of implementing that= in > a fileserver allows that. I think you missed the point. What I have given is an example, what indeed made me wonder, initially, about a way to simply store definitions as a text file, the relationships between the notions being described by a directory structure. It was obvious rapidly that this won't do in a classical hierarchical filesystem. Say it is a "thought experiment". I don't plan to write a fileserver just to implement this example. But multidimensional data is more widely needed than this example. I have indeed cases where a fileserver like that would allow storage of some data already stored in a database (served by a database SQL engine, for example), and for which the classical relational database is simply not a match. Files have the benefits that you can use the text tools on them to grep or whatever. And the file hierarchy reflects what is given by indexing in a relational database. Last, I always find it useful when I program or when I learn to ask me questions about "what if" (as long as I don't spend the bulk of time beating around the bush). One learns with exercices, questions, reading a book a pen in the hand, simply because this is the only way to leave a track in one's mind. Even dead ends are useful, since you know what is possible and what is not.=20 And I may do strictly nothing, at the moment, with some multidimensional stuff, but use some of the solutions sketched, or something thought about passing, or part of a detail, to solve a non directly related=20 problem later. There is a paper by D.E. Knuth, IIRC, speaking about the usefulness of "toy programming". This is it. --=20 Thierry Laronde http://www.kergis.com/ Key fingerprint =3D 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C