From koffice  Fri Jul 02 11:36:16 1999
From: =?iso-8859-1?Q?Robert_Sch=F6ftner?= <r.schoeftner () magnet ! at>
Date: Fri, 02 Jul 1999 11:36:16 +0000
To: koffice
Subject: Re: koffice file formats
X-MARC-Message: https://marc.info/?l=koffice&m=93111367501369

hi,

On Fri, Jul 02, 1999 at 09:14:25AM +0000, Leon Widdershoven wrote:
> Robert Schöftner wrote:
> > > A better idea would be to put the binary chunks at the end of the file.
> > 
> >         no. those binary chunks can become REALLY large (imagine some CMYK 600dpi
> > photos) and we definitely don't want to rewrite that much data with every save.
> > using some hole-in-the-file magic will result in MS Office-like bloating of
> > documents. so there are IMHO not too much alternatives (btw. it did work on the
> > NeXT).
> > 
> > > Or alternatively to make a tarred file the basis of the save file. But
> > > this would mean the savefile is not XML, since it has to be preprocessed
> > > before use.
> > 
> >         TAR would be (in the directory approach) the transportable form.
> > 
> 
> I understand, and agree, that writing these chunks of data each time is
> not
> the way to go. But the alternative is to use multiple files normally, 
> and only tar them when transportation is necessary.

	normal files grouped together in a directory. under NeXT/OpenStep those directories end in .d

> Because, as I see it, if you always tar and untar (transparantly or
> not), you 
> still have to write these chunks of data each time.
> Did I understand correctly?

	except for the "always" *g*.

	in linux-kernel, there currently is a discussion about multi-fork filesystems (it seems that samba could use them, IIRC Windows NT's (or 2000's) FS is capable of storing multiple forks/file, and the office-2000 suit uses these to store its documents more efficiently *sigh*. it is _very_ unlikely that such funcionality will be implemented in linux, becaus it can be trivially emulated with a directory. and, of course, then you don't need those kernel-based office-document conversion filters microsoft needs. :)

	the current approach in koffice is non-standard, and we can't demand that conforming xml-parsers be changed to read those "binary" koffice-"xml"-docs.

	so IMHO the cleanest solution would be to extend KDE's kio_file for documents that are (on the filesystem) directories and so save those "multiparts" in separate pure xml-files into a directory.

	one could argue that users can do bad things to such a beast (in l-k they call such directory-documents "albod", some weird acronym i've forgotten :), delete arbitrary files or do other nasty things. but they could be nasty to a _file_ too. unix never prevented users from doing stupid things in order to allow users to do bright things

servas,
  robert

-- 
In Root we Trust!
   [STOP ENFOPOL:  http://www.quintessenz.at]
   [   campaign mailto:nobody@quintessenz.at]
   [   contact:      mailto:k@quintessenz.at]