From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Beshers Subject: Re: viewprinting: what format should views be stored in? Date: Fri, 20 Aug 2004 08:36:50 -0400 Message-ID: <4125F062.8090908@comcast.net> References: <20040818075216.B920D15DBC@mail03.powweb.com> <4123ABEE.9020001@comcast.net> <4123BA24.2060001@namesys.com> <4123CDB3.2010506@comcast.net> <4123CE91.4090007@namesys.com> <4123E3C9.90006@comcast.net> <4123F77C.6060703@namesys.com> <41240A04.7000502@comcast.net> <41243FA3.1010609@namesys.com> <4124A194.3030902@comcast.net> <4125A169.5080404@namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <4125A169.5080404@namesys.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Hans Reiser Cc: David Dabbs , reiserfs-list@namesys.com Ah, I suspect that this disagreement has more to do with: What should go into the proof of concept implementation? vs. What is needed to win Linux community support? Hans Reiser wrote: > George Beshers wrote: > >> >> include ".|..|[ac-z][b-z][a-qs-z]|...+" >> >> A moments thought and you will see that both can be implemented with >> 5 state finite state autometa (adding a failure/success state as the >> 5th state >> with entire alphabet transitioning to the 5th state). > > > Yes, but you can avoid the transformation and just have a mask that > excludes what it lists. You can have bounce off points instead of > fall through points. True. > You can also have the exclude be a completely separate mask from the > include mask. True. > It is an interesting question whether that is a good or a bad > idea.... it might be a good idea but less space efficient. Also potentially a greater performance hit. >> I completely agree that the exclude clause is much cleaner syntactically >> and the specification compiler should handle them (requirement), but >> I don't think they are a consideration in terms of the "compiled" spec >> that must be evaluated in the kernel as the process is being run. >> >> *Getting Pragmatic >> * >> I have been assuming a model something like the following: >> >> - There is a *presentation mask* format (the mask source) that is >> platform independent and probably human readable. > > > Nah, I no longer think so, I like > > ls -R executable/metas/mask > > as what the humans look at. To gain community support we are going to need a way to ship the masks with the executables, and probably parameterize them for Makefiles. Grant you it is Phase II work, but it will become a requirement. > >> >> - There is a *compiled mask* which is designed to optimize *mask >> evaluation*, i.e., the chroot like semantics. >> >> - The mask evaluation is done by the *mask interpreter* which is >> in the kernel (reiser4 area until we take over the world ;-) ). >> >> - That the format produced by tracing can be converted to a >> presentation mask for user editing. > > > Just use the filesystem tree and create a few fall through and bounce > off plugins. For the proof of concept I agree. Hans, while your points are valid, they are not compelling. The transformations involved have been well understood for 3-4 decades. Ultimately, performance and scalability needs to drive these implementation/optimization decisions and they can and should wait until we have something working and can take measurements. > Proposed definition: > >> >> An extension to the presentation mask language is *syntactic sugar* >> Iff it does not require increasing the complexity of the mask >> interpreter. >> > >