Re: viewprinting: what format should views be stored in?

[George Beshers <gbeshers@comcast.net>]

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.
>>
>
>