Re: Request: Test suite for EFS.

[Mike Bond <mike bond template com>]

On Thu, 24 Feb 2000 13:55:37 Guillermo S. Romero / Familia Romero wrote:
> [Forward to the list if you think it is usefull, I think it does not add 
much]
> 
> >For the 'average' user, the EFS files are just going to be another 
> >proprietary binary file format, they are not going to care that it is a 
> 
> Propiertary, maybe. But I guess the specs will not be hidden like others, so
> the problem is minimum (maximum now, but let pass some time and it will be
> minimum). And always you can save in a different format. ;]
> 

I agree completely, what I meant is that the "average" user isn't going 
to care much about what is inside the file. The rest of us, however, 
will be able to do lots of neat things with it.

> 
> >filesystem within a file. Someone will eventually want to send an email 
> >with their spiffy new spreadsheet that shows the question to the answer 
> >to the universe, life, and everything as an attachment. A directory 
> >would make this very frustrating for this user as this user is just 
> >going to select the "document", send the email, and get a response from 
> >the recipient that the email contained nothing.
> 
> 1 document <-> 1 file is the way some OS handle this. NeXT used a different
> method for applications, but it was build in the system, GNOME can not force 
it.
> 

Yes, GNOME will not be able to enforce making a directory look like a 
single document outside GNOME, as GNOME has no control over the OS at 
large, therein lies the problem with using a directory structure as one 
document.

> 
> >EFS has advantages over the other proposed formats in that it will be 
> >time efficient in saving/loading, but filesystems in a file have the 
> >disadvantage of occasionally have ununsed spots where things have been 
> >replaced but the replacement wouldn't fit, disks are big though, and 
> 
> EFS defrag tool? EFS auto defrag / anti frag?
> 

That would be very nice, another, perhaps additional, approach is to 
keep track of fragmentation and when it reaches a certain point 
automatically "defrag" on a write of the document. Perhaps the defrag is 
simply to rewrite the whole document at that point without the holes, 
maybe a lot faster if there is a lot of fragmentation.

> >most of these dead spots can be minimized. I like the idea of providing 
> >utilities to extract the data, and yes, if we used the zip format, this 
> 
> That is a must, IMHO, there must be a way to extract and create EFS file
> like you create ISO or EXT2 images. A kernel module to mount EFS (project of
> the week? /me ducks and runs) could be a idea for the future, and I guess
> that if the EFS is used we will see the patch for at least Linux and *BSD
> kernels. And maybe even tools for Windows like the ones for EXT2.
> 

This was suggested as an option before, and it would be reasonably easy 
to do.

> 
> >would be done for us, but zip does not handle dead space as efficiently 
> >as possible, in fact not really at all, and I'm not really sure this 
> >tasks requires the compression, or would even really provide sufficient 
> >benifit from having the compression given that one of the objectives is 
> >to provide a mechanism to tie images and other pre-compressed things to 
> >documents.
> 
> IMHO the best is to use a file that behaves as a filesystem and provide
> esf2dir and dir2efs, so you can extract and build, just that. No compression
> at all, except the provided by the formats that go inside EFS file (letter
> with PNG logo, ie). If you want compression use .efs.bz2 or similar aproach,
> like Gimp's XCF way. Or compress the docs inside, so a EFS file has .tga.bz2
> inside. Keep things easy, reuse tools if you can.
> 

I like that, compressing the textual documents that are put into the EFS 
before they are put there. This accomplishes what zip does but only does 
it on the most compressible thing, text.

> 
> I do not see what is all the problem with EFS. IMHO, library + tools +
> kernel mod and you have all basic problems solved, just code it (work in
> progress, no?). I hope this idea will be used, I have been using Blender and
> the file format is similar, thus allowing imports and links from one file to
> another.
> 

You are talking to a bunch of engineers, therein lies the heart of the 
problem, each has their own, usually strongly held, ideas what a perfect 
system would be like. ;-) I'm just curious to see what comes of this 
discussion.

> 
> What is more I hope the EFS would be used to put Unix like FS inside a file
> that grows and shrinks as needed, so you can use it anywhere. Imagine the
> possibilities. It sounds like "make your ISO or EXT2 FS in a file" but newer
> & better (auto resize as space is requested / released). Why do not let the
> coders implement EFS? Let them and then we test it. :]
> 

It was suggested earlier in this discussion to have those in favor of 
EFS prototype, test and benchmark that, those that wanted the zip format 
to do the same, and those that wanted the directory structure to do the 
same. The problem with that is I have a feeling that there are those out 
there that would like to see some end result sometime this decade :P I'm 
pretty sure someone is off doing one of these already as the rest of us 
discuss it.

TTFN
MikeB

Application development is a race between software engineers who
try to create fool proof programs and the universe which is trying to
develop superior fools.
	
	So far, the universe is winning.
	Let's not give it any help...