CRUSH plugin about squash HOT 2 CLOSED

I'm interested in helping with this one, as well as data-shrinker. Does the patch at the following location represent the amount of changes needed to integrate a new codec?

http://pastebin.com/gn60AEFs

Or is there additional work needed (beyond the implied work such as verifying it all checks out okay)? And in particular is the code in a good place for this kind of integration or are there anticipated API changes?

from squash.

I'm interested in helping with this one, as well as data-shrinker. Does the patch at the following location represent the amount of changes needed to integrate a new codec?

In general yes, there are a lot of plugins like that. There are two common API types out there which it's really easy to integrate with Squash, and libzlg follows one of them (it's the same type of API as LZ4, Snappy, LZF, FastLZ, etc.). The other one is a zlib-style stream API (like zlib, bzip2, and liblzma use).

CRUSH will require a bit more work because there is no API designed to allow you to use CRUSH as a library. Basically, fixing this issue will require some significant changes to CRUSH. I'm considering adding some code to Squash which will handle FILE* stream APIs transparently (by using a thread and pipe(2)), but I'm leaning towards not doing it since it's really hackish and performance would suck. That said, it would make CRUSH, BALZ, zlite, etc. trivial to integrate.

If you want, I'm nemequ on IRC (FreeNode and GIMPNet), or at gmail.com for XMPP. That's a bit more convenient than the issue tracker if you have trouble while you're working on a plugin.

Or is there additional work needed (beyond the implied work such as verifying it all checks out okay)? And in particular is the code in a good place for this kind of integration or are there anticipated API changes?

The liblzg example is a good place to start, CRUSH definitely wouldn't be. I don't plan any backwards-incompatible API changes for plugins, but I'm not making guarantees yet.

from squash.