On Thu, Dec 10, 2009 at 1:34 PM, Sam Van Oort <[email protected]> wrote: > Hi, > I can add this to a list of extensions to the LZF code. It's not a > bad idea to have a version which is fully binary compatible, which can > be used as a compatibility option in the future.
I think it'd be nice to be compatible, especially if a separate library was carved out. Also: using chunk identifiers like command-line tools has one nice benefit; that is, you can just sequence blocks without restrictions as there is no initial header (which can be downside in some cases too). > Hopefully, I can add this once my higher-compression extensions to LZF > finish code review (*cough cough*). As it stands, the H2 LZF code What kind of improvements are there? Better hashing? I assume changes to format wouldn't be needed? > outperforms QuickLZ's Java version, when it comes to compression and > decompression speeds (although it does not compress as much). I think > this part of the project is strong enough that with a few extensions > it could stand on its own. Yes, many other projects have expressed interest in using a pluggable codec. -+ Tatu +- -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
