|
Boost : |
From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-10-03 13:48:30
"Pavel Vozenilek" <pavel_vozenilek_at_[hidden]> wrote in message
news:cjlkfo$mcl$1_at_sea.gmane.org...
>
> "Jonathan Turkanis" wrote:
>
> > > ... and lzo as well, please.
> >
> > I wrote an LZO wrapper but didn't include it because of licensing concerns.
If I
> > am assured that I can write a wrapper intended to be used with GPL'd
software
> > without the wrapper being covered by the GPL, I'll defintely include it.
> >
> It would be most unfortunate technical progress being hindered by such
approach.
Agred. The reason I bong it up is that I remember someone saying some like this:
it's clear that under European Union law wrappers would not be covered by GPL,
but under US law it might not be so clear.
> > It would be nice to include filters that can read and write Markus
Oberhumer's
> > lzop file format, but it does not appear to be documented and he never
responded
> > to an email I sent him. I assume there's a header specifying compression
options
> > and some metadata and a trailer containing data length and a checksum, but
it's
> > difficult to decipher the source code.
> >
> LZO is absolutely undocumented and its code is one big mess
> (but works).
Good, so it's not just me ;-)
> AFAIK Markus Oberhumer can't be reached
> for long time by anybody.
> > I'm definitely expecting more compression methods to be added in the future.
I
> > also hope that other people will write some of them ;-)
> >
> I guess this will happen. There are few very promissing
> compression technologies (say LZMA) around and
> lot of good implementations of proven ones.
> This also lead me to question: is there example of any
> encryption/decryption filter in Iostreams?
Not yet.
> There are quite many of them in C++, each using their
> own conventions and it may happen someone will
> normalize them to be useable within Iostreams.
I thought of writing wrappers for the crypto++ library, which I have used
successfully before. However, the library's documentation is terrible. Also it
is large, takes a long time to build and provides it's own chaining mechanism,
so I'm not sure how useful wrappers would be.
If you know of some links to fairly self-contained implementations of
cryptographic algorithms, could you post them?
Jonathan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk