Re: RFP: CompoundStorage document



On Mon, 2002-04-15 at 18:55, Rui Miguel Silva Seabra wrote:
> On Mon, 2002-04-15 at 17:40, Martin Sevior wrote:
> > Ok I can see this argument but I can easily imagine an abiword compound
> > document consisting of XML encoded data items with mime-type labelling
> > each item. So for example an embedded gnumeric spreadhsheet is just a
> > another image type with a data item that labels it as a gnumeric object
> > and the actual description of the spreadsheet in ordinary gnumeric XML
> > being the cone=tents of the data item. 
> > How do subfolders help us?
> 
> Well, firstly, xml isn't a silver bullet.

right.

> Secondly, you'd have to parse a complete file (almost as slow and
> continuous as a tar.gz).
> 
> To have more that one type of document, it is a lot better to have a
> virtual filesystem where you can put everything inside in seperate
> compounds: images, embedd/spreadsheet, embedd/escher, etc...
> Then you could just load the document, present it painlessly, and have a
> progressive loading of the remaining alien stuff.
> 
> zip files provide an easy way and fast way to have a virtual filesystem
> (and it is even compressed).
> 
> the java guys did a right thing with .jar's, and it is not a bad idea.

I cant see why someone want to use tar files to store compound
documents. We have special formats (OLE2/libefs) which do a much better
job for compound documents (incremental save, encryption, compression,
transactions).

- Dietmar





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