On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri <vincent.to...@gmail.com> > said: > > actually forget lz4hc... lgpl3. > >> hey >> >> just found that while reading the gnutls ML : >> >> http://code.google.com/p/lz4/ >> >> it seems that it allows the same ratio for compression than zlib but >> seems to be by far faster than zlib >> >> the memory consumption should be tested too. >> >> What do you think ? >> >> Vincent >> >> ------------------------------------------------------------------------------ >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
I don't see any problem using an LGPLv3 library. Are there really any changes necessary to make use of it in eet? Also, would it have to be distributed in a way where LGPL parts would actually be packed into an Eet binary or Eet source code? Although I of course can understand that it would not be possible to use Eet in an environment where no LGPL library could be accepted, wherever or whyever that would be. Other than that, would it really be worth it? Even if in the best case the compression is only a little worse than zlib and compression time would be a lot faster - would it really be worth it? Eet usually is used WORM-style (Write Once / Read Many), so compression time is hardly an issue - but if decompression is not significantly faster (or even slower?), and file size is larger (thus I/O, which more often than not is a bottle-neck nowadays, being lower) you'd actually not gain anything but lose run-time performance instead. On the lz4hc page I only spotted compression benchmarks, nothing about decompression - if basic information is missing, there usually is a reason. If anything, what would make sense for Eet would be the XZ format, using LZMA. Compared to zlib, compression is a lot slower, but decompression is not much slower - and compression ratio and through that I/O throughput a lot higher. XZs liblzma is LGPLv2.1 though. Lastly: why would it be trouble supporting additional compression methods? Eet uses file format versions in the binary, right? Why not have features supported starting from a certain format version? Sure, that would make old files incompatible but would this really be an API-break? As I see it it would just mean newer files, or programs using newer files, would have to depend on a newer minor release of Eet without any actual API changes (in any case though it is an ABI change for the Eet files I guess). A way to do such a change might be having a new major release for it and default to the old zlib compression, so users who require for example XZ support can depend on it properly and not risk producing files nobody can use, for no reason. ~thomasg ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
