On Wed, Jul 16, 2003 at 04:28:18PM +0100, "Adam D. Moss" <adam@xxxxxxxx> wrote:
> Technically I don't know if that's true. From my ar man page:
> GNU ar can maintain archives whose members have names of
> any length; however, depending on how ar is configured on
> your system, a limit on member-name length may be imposed
> (for compatibility with archive formats maintained with
> other tools). If it exists, the limit is often 15 charac-
> ters (typical of formats related to a.out) or 16 charac-
> ters (typical of formats related to coff).
>
> But, that is of no consequence -- we wouldn't need to keep
The "archive formats" that the ar manpage above refers to are what mortla
people call "object files". Since ar is part of binutils it tries to be
compatible to other object formats which often have severe limitations.
ar also handles hierarchical structures within ar files, but for
compatibility it doesn't create them.
(and there are common extensions that allow unlimited name lengths, these
are also handled by ar).
> can easily be talking HUGE) temporary intermediate file. In
> this case something like a ZIP (or okay, equivilently, a compressed
> jar, whatever you want to call it) is a better (and still
> exceedingly standard in its most basic form) choice of
> wrapper for the hierarchy-file-plus-linked-resources.
"something like zip" is the key. zip won't do, of course, since it's lousy
at compression and also doesn't support random access like we want. Also,
I think compression at the file level (whole file) is not a good idea
anyway, so we could keep a simple wrapper format (like ar) and implement a
more intelligent block structure within the constituent files.
However, the reason why people propose ar, jar, cpio etc... as formats
is that they cna be handled by users with ease, being well established.
If we would design our own extremely simple wrapper format there would be
no need to work with the compatibility mess existing formats are (all of
them :). If we say that access by other tools than gimp is not important
we could get away with an extremely simple format, say, cat files*, index
at end which could be just offset and length, indexed by number, meta-info
is all handled by an xml "sub"-file.
The question is simply wether it should be a standard format or not.
If we want to implement a kind-of tile cache within the image to speed up
loadign and operations, using a format like ar/jar/etc. would just be a
hindrance, as users wouldn't be able to deal with the "files" within them
anyways.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
