Anyone considered LZMA support?

[Nelson]

It compresses better than Bzip2 and it decompresses quite a bit faster.

[Rob Braun]

No objection to including LZMA here. Do you have patches?

Rob

[Nelson]

I'm working on some. What's the interface in the bzxar and zxar
files? Is the same block of memory used for input and output?

[Rob Braun]

On Sun, Jul 15, 2007 at 06:43:56AM -0700, Nelson wrote:
>
> On Jul 10, 11:27 pm, Rob Braun <bbr...@synack.net> wrote:
> > No objection to including LZMA here. Do you have patches?
> >

> > On Tue, Jul 10, 2007 at 06:50:45PM -0700, Nelson wrote:
> >
> > > It compresses better than Bzip2 and it decompresses quite a bit faster.
>
> I'm working on some. What's the interface in the bzxar and zxar
> files? Is the same block of memory used for input and output?

There are basically two forms for the api, extraction and archival or
"fromheap" and "toheap", the heap being the portion of the archive
the actual files exist in.
Within each of these forms there is an in, out, and done. The "in"s
are all called before the "outs", and "done" is called after all of
them. The reason is we do reuse the same buffer as you mentioned.
However, some modules, such as the hashing module, want to see
the data both in its original unmodified state, and in its final
state. So, it runs first in the "in" chain, and then again in the
"out" chain. All modification is expected to happen during the
"in" phase, and "out" is merely for observation.

To add a module, you simply modify xar/lib/io.c and add a struct
pointer to the various functions. Order here does matter, and
adding such a module is probably best to append to the end of
that array.

Rob