Re: Request: Test suite for EFS.

[Daniel Veillard <Daniel Veillard w3 org>]

On Thu, Feb 17, 2000 at 06:37:02PM -0600, Miguel de Icaza wrote:
> Dont tell me you really believe XML is the right approach for
> file-system-inside-a-file problem.  And yes, Eazel should be among the

  Even I don't believe that...

> first ones to realize that having a document split into 40 pieces is
> not right.  And it does not take a rocket scientist to figure out that

  That I say really depends how you access this document.
As far as i know our beloved docbook system does break document 
on multiple pieces, it is usable. 
  I maintain that on a distributed FS space with metadata like
a WebDAV enterprise wide filesystem keeping isolated resource
is the Right Way to do things.

> using XML for a file-system-inside-a-file is not exactly what we call
> efficient in my town.  Perhaps in yours, but not in mine. 

  Neither in mine for generic data. For gnumeric + wordprocessor
output + svg graphics, yes! This can cover 80% of the productivity
application space ... But it's not the general case.

> So, lets please go back to the problem at hand, and this time, please
> keep your nit-picking aside, lets try to solve a problem, not debate
> whether we can fit another angel or not in the tip of my pen.
> 
> Problem: We need a way to keep compound documents in a single file.
> Problem: It must not be utterly stupid to do so.
> Problem: It must allow containee components to write their own
>          information into a specific name space.
> Problem: It must be as compatible with other systems as possible.
> Problem: It must fit large files, for example handle a 100 megabyte
> 	 file without problems on small memory machines.

  a Zip/Tar/Ar file with 

    a fist file containing document metadata
    all the (local) document resources

local in the sense that the metadata may indicate a remote URL for
components you don't want to embbed in. 

  for memory requirements, it seems as the RPM guys decided that ar
was easier to change/edit on smaller machine. I would discuss
this tradeoff with people designing the RPM/dpkg format and its 
successor.

Daniel

-- 
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
Tel: +33 476 615 257  | 655, avenue de l'Europe | Linux XML libxml WWW
Fax: +33 476 615 207  | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
 http://www.w3.org/People/all#veillard%40w3.org  | RPM badminton Kaffe