Re: RFP: CompoundStorage document
- From: Dietmar Maurer <dietmar ximian com>
- To: Rui Miguel Silva Seabra <rms 1407 org>
- Cc: gnome-office-list gnome org
- Subject: Re: RFP: CompoundStorage document
- Date: 15 Apr 2002 19:47:40 +0200
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]