nemequ
commented
7 years ago Sorry about the delayed response; I'll get to the reason in a minute…
There are three ways this can be interpreted, each has a slightly different answer:
- Is it possible to support LZ5?
- Will you add LZ5 support?
- Would you accept a patch for LZ5 support?
Is it possible to support LZ5?
I haven't looked at the API in detail yet, but I'd be quite surprised if it isn't. We already have an LZ4 plugin, and LZ5 was forked from LZ4. Honestly, it's probably possible (even relatively easy) to support just about any compression codec.
Will you add LZ5 support?
I don't have any short-term plans to add additional plugins myself. There are other areas of the code where my attention is needed more. I'd like to encourage more community involvement, especially in the plugins.
Long-term, I'd like Squash plugins for everything.
Would you accept a patch for LZ5 support?
This is the reason for the delay. I've been thinking about how to answer this.
Ever since LZ5 was released I've been uncomfortable with it because of the name. "LZ5" implies that it is the "successor to LZ4" (i.e., LZ4 2.0), or at least an "upgraded" version, which isn't fair to LZ4. LZ5 simply makes different trade-offs.
To be clear, I'm completely fine with the idea of forking LZ4 to create a new codec; it's only the project name I'm uncomfortable with.
There are a lot of problems with implying such a link with LZ4, such as
Support
People are likely to go to LZ4 for support, which isn't fair to the authors of LZ4.
My favorite example of the type of issue this could cause is a comment from SQLite:
The default prefix used to be "sqlite_". But then Mcafee started using SQLite in their anti-virus product and it started putting files with the "sqlite" name in the c:/temp folder. This annoyed many windows users. Those users would then do a Google search for "sqlite", find the telephone numbers of the developers and call to wake them up at night and complain. For this reason, the default name prefix is changed to be "sqlite" spelled backwards. So the temp files are still identified, but anybody smart enough to figure out the code is also likely smart enough to know that calling the developer will not help get rid of the file.
Diluting LZ4's brand
If people think there is a link between LZ4 and LZ5, any problems with LZ5 are likely to influence their perception of LZ4, which isn't fair.
Leeching off of LZ4's brand
LZ4 has created a very good image of itself by being really good at what it does. Other projects should be able to build their own reputations based on their own quality instead of using LZ4 for a head-start.
With all that said, I want to be very clear that, AFAICT (I haven't really looked at LZ5's code) everything seems to be pretty well-done. However, all the points above still stand, even if LZ5
- Maintains a high standard of quality, including portability and security
- Provide clear attribution of the history of LZ5 (as a fork of LZ4)
- Makes it clear that LZ5 is not associated with LZ4
- Provides reasonable support, and bug fixes for any issues discovered.
I'm going to assume that LZ5 does, and continues to do, all those things. Every indication I've seen is that they do. No matter what else they do, though, the "LZ5" name still muddies the waters.
To be clear, these are my own opinions. I don't think we should involve Yann in this conversation (especially not publicly), as it would put him in a very difficult position.
I'd like to add that, because of the name, I've been hesitant to add an LZ5 plugin. It's quite possible other people will have the same concern, so it may actually be in LZ5's best interest to change their name.
In the end, I think that yes, I'd be willing to accept a patch for an LZ5 plugin, so long as the documentation made its relationship with LZ4 extremely clear. I'd feel a lot better about it if LZ5 had a different name, though.
Could support be added for lz5?
https://github.com/inikep/lz5