[Evolution-hackers] Backporting EWS GAL changes to 3.8

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

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...


Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]