[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: koffice file formats
From:       Robert_Schöftner <r.schoeftner () magnet ! at>
Date:       1999-07-02 11:36:16
[Download RAW message or body]

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]


[prev in list] [next in list] [prev in thread] [next in thread]