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

List:       koffice
Subject:    Re: koffice file formats
From:       Jim McCusker <jpmccusker () yahoo ! com>
Date:       1999-07-05 16:57:32
[Download RAW message or body]

--- Robert_Schöftner <r.schoeftner@magnet.at> wrote:
> 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

We are having a similar discussion on the katabase mailing list. Because
of the file formats that we have to deal with (separate tab-delimited
files), we are going to make a directory structure. Will there be tar
support for such a beast in the future?

Jim
===
Jim McCusker | mccusker@iname.com http://cif.rochester.edu/~fprefect
"Another of Fortran's breakthroughs was the GOTO statement, which was a \
uniquely simple and understandable means of structuring and modularizing \
                programs."
--May/June'94 IEEE Institute
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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