Re: The... reiser4 with no ambiguity

[Edward Shishkin <edward.shishkin@gmail.com>]

Ralph Ulrich wrote:
> Edward Shishkin Wednesday 17 December 2008 22:49:
>   
>> I am a bit disappointed: I wanted to concentrate efforts
>> on the Linux port..
>>     
>
> I would like to create some kind of reiser4-SDK where 
> more people can easily experiment with reiser4. 
>   

I am skeptical about expediency of the end product,
especially after taking into account its possible high
cost:  why people can not experiment with reiser4,
say, in uml (user mode linux )?

> In my vision reiser4 has a big future as a specialized 
> filesystem: A filesystem where you can add special features/logic/semantics perhaps even dynamicly. 
>   

Imho specialized filesystem is something like ramfs ;)

> I need a different reiser4: A minimal reiser4 "kernel" with 
> common features,  this r4-kernel then loads extensions 
> special to a r4 partition directly from that partition. 
> I mean the defenitions of extensions but also the code 
> of these extensions. So there has to be a common 
> interpreter of such extensions included in a r4-"kernel".
>
>   

> This way every r4-"extended"-partition can serve a 
> different purpose. Eg think of some semantic 
> extensions special to music. Users would mount 
> a specialized r4 partition at
> /home/username/mymusic
> Or for pictures .... etc
>
> I believe reiser4 has a big future with its capabilities 
> in a field of special storage. Think of all the new
> little "iphone" devices. 
>  
>   
>>>  (probably D: has clean syntax, has classes and
>>>       
>> yup, object-oriented means would be a plus.
>>     
> A rewrite would have self-educational purpose for me 
> personally and could have documentation effects 
> (if done proper) for reiser4 in general.
>
>   
>>> Could reiser4 fit well to my purpose ?
>>>       
>> You might want a high-performance reiser4 storage level
>> with EOTTL technology.
>>     
> EOTTL ??
>
>   

yes, "extents on the twig level", the favourite Hans' feature..

>   
>>> The first part of my work would be to enable a special place
>>> on disk for definitions of used plugins.
>>>       
>> Sorry, can not understand the above.
>>     
> See above notes!
>   

Why to not load the "extensions" from a file?
I don't think, that additional formats to store it
on a "low level" is a good idea and the first
issue to resolve...

Edward.