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

List:       koffice
Subject:    [Fwd: Koffice file format woes]
From:       Werner Trobin <wtrobin () carinthia ! com>
Date:       1999-08-15 5:58:26
[Download RAW message or body]

I thought you all might want to read that.

Werner

Return-Path: <kefka@godmode.penguinpowered.com>
Received: from godmode.penguinpowered.com (blah@dt069n09.san.rr.com [204.210.34.9])
	by darth.carinthia.co.at (8.8.7/8.8.5) with SMTP id XAA10179
	for <wtrobin@carinthia.com>; Sat, 14 Aug 1999 23:53:14 +0200
Received: (qmail 6530 invoked by uid 501); 14 Aug 1999 21:49:08 -0000
Date: Sat, 14 Aug 1999 14:49:08 -0700 (PDT)
From: "Dr. Gene Scott" <genescott@geocities.com>
X-Sender: kefka@godmode.penguinpowered.com
To: wtrobin@carinthia.com
Subject: Koffice file format woes
Message-ID: <Pine.LNX.4.10.9908141434200.6526-100000@godmode.penguinpowered.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mozilla-Status2: 00000000


I read on the kde-koffice list about the proposed file format and got a
bit worried, I'm not sure how to mail the list so I'm mailing you. :)

Having the file format be a .tgz is not that great an idea.  To access one
element of a .tgz file you'll probably have to decode the entire thing,
it's not indexed storage in any way.  This would mean Koffice would only
be able to do two things: decode the entire thing into memory/disk or
decode the archive each time it needed to search for a file.  People are
going to want to make large things with Koffice.  Reading the whole file
into memory is just not an option with big files, and finding a single
file in a .tgz takes about the same ammount of time as un-tgz'ing the
entire file, which would be a horrible thing on large files.

As I see it, Koffice really would need an indexed file format.
Compression, if desired, would be done on a per-object stored basis, not
on a per-file basis.  The simplest way of thinking about this is instead
of having a .tgz, you'd have a .tar with each file inside being gzipped
and an index at the head of the tar pointing to the position of each file.
I think cpio/afio might already act this way but I'm not sure, it'd be
worth looking into though.

I would hate having to wait 15 minutes to read the cover page of a report
that also includes a large mpeg animation. :)



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