[Haskell-cafe] ANNOUNCE: iteratee-compress 0.1.1
Maciej Piechotka
including flushing. Currently only gzip is provided but at least bzip
is planned.
Changes from previous version:
- Independent from zlib library (Haskell one, not C)
- Allow hand-flushing the contents (from outside).
- Fix potential memory-leak
Next goals:
- BZip support
- Generic interface for flushing
To think about:
- Should inner iteratee be able to request flushing?
Regards
PS. It did change API by removing dependency on zlib but I home such
breakage in 0.1.x will be allowed
wren ng thornton
> Iteratee-compress provides compressing and decompressing enumerators
> including flushing. Currently only gzip is provided but at least bzip
> is planned.
>
> Changes from previous version:
> - Independent from zlib library (Haskell one, not C)
> - Allow hand-flushing the contents (from outside).
> - Fix potential memory-leak
>
> Next goals:
> - BZip support
> - Generic interface for flushing
Have you thought about adding LZO[1] support? There'd be the usual
licensing issues for GPL, but it offers a realtime alternative to gzip
(i.e., decompression time is hidden by I/O latency) with comparable
compression performance.
[1] http://www.oberhumer.com/opensource/lzo/
--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Maciej Piechotka
> On 10/24/10 7:09 AM, Maciej Piechotka wrote:
> > Iteratee-compress provides compressing and decompressing enumerators
> > including flushing. Currently only gzip is provided but at least bzip
> > is planned.
> >
> > Changes from previous version:
> > - Independent from zlib library (Haskell one, not C)
> > - Allow hand-flushing the contents (from outside).
> > - Fix potential memory-leak
> >
> > Next goals:
> > - BZip support
> > - Generic interface for flushing
>
> Have you thought about adding LZO[1] support? There'd be the usual
> licensing issues for GPL, but it offers a realtime alternative to gzip
> (i.e., decompression time is hidden by I/O latency) with comparable
> compression performance.
>
>
> [1] http://www.oberhumer.com/opensource/lzo/
>
Currently I thought only about bzip2/gzip. Probably .xz support would
follow if any.
LZO, as you said, is on GPL-2. While I have no problems with GPL-2 some
potential users may (Haskell tend to be BSD3 community). Does anyone
knows if conditional compilation solves problem? In my interpretation of
GPL-2 yes but I'm not sure.
Regards
Felipe Lessa
> Currently I thought only about bzip2/gzip. Probably .xz support would
> follow if any.
>
> LZO, as you said, is on GPL-2. While I have no problems with GPL-2 some
> potential users may (Haskell tend to be BSD3 community). Does anyone
> knows if conditional compilation solves problem? In my interpretation of
> GPL-2 yes but I'm not sure.
Conditional compilation is tricky for licensing purposes, I think.
But a 'iteratee-compress-lzo' or 'iteratee-compress-gpl' package would
definitely avoid such issues.
Cheers!
--
Felipe.
Conrad Parker
version numbers are cheap :)
Conrad.
wren ng thornton
> On Sun, Oct 24, 2010 at 9:59 PM, Maciej Piechotka<uzytk...@gmail.com> wrote:
>> Currently I thought only about bzip2/gzip. Probably .xz support would
>> follow if any.
>>
>> LZO, as you said, is on GPL-2. While I have no problems with GPL-2 some
>> potential users may (Haskell tend to be BSD3 community). Does anyone
>> knows if conditional compilation solves problem? In my interpretation of
>> GPL-2 yes but I'm not sure.
>
> Conditional compilation is tricky for licensing purposes, I think.
> But a 'iteratee-compress-lzo' or 'iteratee-compress-gpl' package would
> definitely avoid such issues.
I was going to suggest iteratee-compress-gpl...
--
Live well,
~wren