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

List:       kde-devel
Subject:    Re: "Compound file" library?
From:       Sirtaj Singh Kang <ssk () physics ! unimelb ! edu ! au>
Date:       1998-11-05 8:25:21
[Download RAW message or body]


On Wed, 4 Nov 1998, Russ Steffen wrote:
[snip]
> I think I'd take a shot a at it. I've written a lot of code for pulling
> apart IFF files and putting them back together in the past, but it was 
> all in C and 680x0 assembler. It should be interesting to put a C++ 
> interface on to that.

Excellent! Thank you for volunteering. :)
 
> Just wondering if I should stick to the spec exactly or should some liberties
> should be taken. The spec specifies that segements in the file be identified
> by 4 character tags, which can be kind of limiting, and it also specifies that
> all data be stored as big-endian. I'm all for following the spec closly but
> I'd be open to suggestions.

Ok, then here are some:

1. I'd really like the mime-type of the data to be as accessible as the
name, which means that it should probably be stored as part of the index
or somewhere just as easily reached without needing to seek to the file
data.

2. Assume that the data is just a byte-stream, so you don't have to worry
about byte order there. For other stuff where a specific byte-order is
required, it will be best to stick to network order (ntoh*/hton*
functions). 

3. I don't think compatibility to the original IFF format should be a
primary concern. Extensibility of the format (ie ability to add more
attributes to the resources than just mimetype and name) might be more
important. 

Just being able to add/modify/remove/access files and their attributes is
all you need to worry about in the library. I will worry about plugging it
into Qt/KDE. Also, if you prefer, feel free to write the entire library in
C.

-Taj.

Sirtaj S. Kang       taj@kde.org         ssk@physics.unimelb.edu.au
School of Physics    Univ of Melbourne   KDE: The Desktop sans Toga

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