Re: Request: Test suite for EFS

He's right. but .tar, not .tar.gz.
It would solve everyone's problem.

The people who want portability get it. Tar has been around for a long
time, and will continue to exist for a long time. Tar is also portable to
non unix systems so if someone wants to create an excel gnumeric file
importer it would be very easy to do compared to a libefs one. Also, it
could work with the command line tools.

The xml people will be happy since gnumeric and all the other apps can
continue to use xml easily.

The people who want speed for searching and other things get it because it
will be filesystem in structure.

The learning curve will be less also. Since everyone wont have to learn
both gnome-vfs and libefs, it will take less time to learn.

It will take less code. Since gnome-vfs will have (if not already has) tar
support, we could just use that. Also, there would be no need for a second
nautilus view since the tar one would work just fine.

Useing gnome-vfs with tar support would be the perfect solution.

On Wed, 16 Feb 2000, Dermot Musgrove wrote:

> Kent Schumacher wrote:
> [...]
> > Could there be such a thing as a compiled indexed XML file that could
> > be compiled (or decompiled) using separate programs (much like tar
> > operates).
> > 
> > Programs could load specific tagged items via a call that supplies
> > an arg list of tags to be retrieved.  The call would have the responsiblity
> > of determining if the file was XML or compiled and behave appropriately.
> > 
> > Then you could get the efficiency of binary indexed files and not give
> > up the ubiquity of XML files.  The user could choose which he preferred
> > on a file by file basis.
> Hi, please ignore me if I am speaking out of turn here but...
> If gnumeric can handle .gz files maybe it could handle .tar.gz files as well.
> Couldn't a (gzipped) tarball contain images, XML, po files and  so on for
> easy (and standard) retrieval?
> The tarball could be released as a chunk of resources but we could all get 
> at the data within if we wanted to use the program's resources without 
> (re)inventing any more 'proprietory' file formats. 
> I am not a C programmer so I don't know what problems this would cause for
> C programs - please ignore me if I am talking rubbish - but it seems a shame
> not to leverage existing code.
> Just my 0.02 euro
> Dermot
> -- 
>         FAQ: Frequently-Asked Questions at
>          To unsubscribe: mail with 
>                        "unsubscribe" as the Subject.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]