And what is it with curse.com and the extreme delay on approving new downloads? Is there another site that is more reliable? wowinterface.com maybe?
If you're using source control, the delay is somewhere between 1 and 20 minutes. Occasionally it'll delay longer if the repository manager has crashed, but that usually fixes itself after a few hours. What are you seeing?
If AceComm-2.0 handles it's own encoding, I see no reason to also handle it here. I would think anyone using this library would also be using Ace to some degree. I am a fan of AceComm-3.0, which is a lot more minimal (but doesn't support channels and such IIRC, so it wouldn't work for GuildAds). I personally see 2 uses for compression -- either direct addon-to-addon communication, or stored in saved variables. Since AceComm-3.0 doesn't encode \000 characters (I don't believe), it needs to happen somewhere else.
If you're really going to get into other types of encoding, then maybe this should be made into a separate library. If you're only going to encode for \000, I think it should just be built in, since that character is disallowed everywhere (or could be if it's not).
However, the argument for inclusion of all encoding methods in LibCompress is this: LibCompress will only be used in WoW. WoW requires some kind of encoding for all uses of strings, period. Therefore, in order to provide an end-to-end solution, LibCompress should handle encoding. Otherwise it will always be useless without some other library included.
After rereading my post, I realized something: AceComm is probably the issue (though not directly). I've been forgetting to deal with / ask about the \000 issue. I bet sending the result of CompressHuffman through the SendAddOnMessage API is causing the problem. If so, this should be dealt with in LibCompress -- I am certainly not going to go through a bunch of extra hoops to further encode the data so it is safe to transmit.
Well, the issue is only triggered by DecompressHuffman. DecompressLZW does not cause it. I can't imagine what sort of "general problem" I could be causing -- my code is only doing exactly what you've done, using the same data. If the issue exists in AceSerialize or LibCompress, that's out of my hands to deal with. I suppose there could be something funky going on even further up the call stack, like in CallbackHandler or AceComm-3.0, which are the other libraries involved here. You probably need to replicate my entire call stack to repro the issue. Well, I don't want to mess with it -- I just won't use LibCompress. I appreciate you looking into it!
You can get AceSerializer-3.0 by going to files.wowace.com and downloading the Ace3 package. Bring the library into your add-on by putting it in a Libs folder and adding Libs\AceSerializer-3.0\AceSerializer-3.0.xml to your toc (or to embeds.xml). From there, add the mixins to your add-on object like so:
After that, it's easy to serialize and deserialize an object:
local serializedData = self:Serialize(someData)
someData = self:Deserialize(serializedData)
Note that your add-on doesn't need to use Ace3 to embed this library as shown.