I've implemented a bunch of fixes to the offline addressbook handling in evo-ews master, and I'd like to backport them to 3.8. In fact I've done *all* my testing on the gnome-3-8 branch and haven't tested master at all as I've been working. (Naughty dwmw2). The code I'd like to push is at git:// or http://git.infradead.org/users/dwmw2/evolution-ews.git We had a local copy of the LZX decompression code, taken from libmspack and then hacked up somewhat to support the variant that the EWS GAL uses. I cleaned up that code and got it accepted into upstream libmspack, and libmspack 0.4 has been released a week or two ago. As part of that process, the libmspack maintainer spotted a number of bugs in our changes. These have all been fixed in the 0.4 release. I've fixed the build in master so that we either need to build with libmspack 0.4 as an additional dependency (recommended), or use a configure option to build with our internal version of the decompression code instead. If you configure without an appropriate libmspack, the resulting error will tell you about the --with-internal-lzx option. I've fixed the most egregious of the bugs in our internal copy, but we'd still be better off using the real libmspack. Our internal version doesn't check CRC on its output, for one thing. And it's non-trivial to add, because of the differences between the two code bases. As well as the LZX fixes, I've also implemented incremental downloads. My own company's addressbook was a 30M download for the full database, and it changes every 12 hours. Now it's only a few hundred KiB each time. As I have an an ADSL line where I pay for daytime bandwidth, I consider this an important bug fix rather than purely an enhancement :) So... I understand that we don't like forcing people to add new dependencies or even to change their ./configure flags in a stable release, but I think that backporting all this as-is is actually the right thing to do. We should never have been shipping a hacked-up copy of a third-party shared library *anyway*. I know it violates the Fedora packaging guidelines, and probably for other distributions too? Opinions? I know Milan wasn't happy about even requiring the --with-internal-lzx option to preserve the (broken) status quo in 3.8, but then disappeared from IRC before I could try to justify its necessity. We *could* make it automatically do the "right" thing, using libmspack if it's available or silently falling back to the internal version. But some people hate configure scripts doing that, and I've already changed master *not* to do it that way... -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature