From: Jameson Graef Rollins <jrollins@finestructure.net>
To: Austin Clements <amdragon@MIT.EDU>
Subject: Re: [PATCH v4 1/7] cli: use typedef to deal with gmime 2.4/2.6
	incompatibility
In-Reply-To: <20120525144136.GB11804@mit.edu>
References: <1337812843-14986-1-git-send-email-jrollins@finestructure.net>
	<1337812843-14986-2-git-send-email-jrollins@finestructure.net>
	<20120525144136.GB11804@mit.edu>
User-Agent: Notmuch/0.13+24~g16915cd (http://notmuchmail.org) Emacs/23.4.1
	(x86_64-pc-linux-gnu)
Date: Fri, 25 May 2012 08:47:59 -0700
Message-ID: <87wr40s1n4.fsf@servo.finestructure.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"
Cc: Notmuch Mail <notmuch@notmuchmail.org>
Precedence: list

--=-=-=

On Fri, May 25 2012, Austin Clements <amdragon@MIT.EDU> wrote:
>> diff --git a/notmuch-client.h b/notmuch-client.h
>> index 19b7f01..337409f 100644
>> --- a/notmuch-client.h
>> +++ b/notmuch-client.h
>> @@ -36,6 +36,8 @@
>>   * these to check the version number. */
>>  #ifdef GMIME_MAJOR_VERSION
>>  #define GMIME_ATLEAST_26
>> +#else
>> +typedef GMimeCipherContext GMimeCryptoContext;
>
> I like the typedef idea, but I don't think we should overload
> GMimeCryptoContext like this.  If someone is reading through the GMime
> 2.4 code and sees this, they're going to assume that it's a GMime
> structure, go looking for it, find that it's only in 2.6 and be
> baffled.  Instead, how about providing a typedef to abstract *both*
> cases?  Something like
>
> #ifdef GMIME_MAJOR_VERSION
> #define GMIME_ATLEAST_26
> typedef notmuch_crypto_context_t GMimeCipherContext;
> #else
> typedef notmuch_crypto_context_t GMimeCryptoContext;
> #endif

Hey, Austin.  I briefly thought about this, but it seemed kind of heavy
handed given that I hope these ifdefs will go away in the
not-too-distant future.  Do we really have a lot of gmime 2.4 readers
that would not have access to gmime 2.6 documentation?  I'm pretty sure
that I would personally end up looking at documentation for both
versions.

But anyway, if this really is a concern, I guess it's not *that* much
effort to support a new typedef indefinitely to alleviate any potential
confusion.

Any other opinions?

jamie.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPv6mvAAoJEO00zqvie6q81PkQAJ8N81j8voiwBwuTbnqx1pV5
QunogNVwa6qtcvh+Np0heG6GRw5ABbjPRlouZZeAIsZQLgVY9RIUndAfHmvXXMsy
ZhHtZaSYK7PyASFx1X76lYGXcApiobj6GDJr/aErfNHi2+jMmQQMF1iNoo77m7qk
KC1MkkbTXTK+XdGyBynv2TtBQIIJGjifXdeYTtoYZfiPjBTZdwAgga8sSO0TADFd
ti5cQrOggzgsH7bT1ucF4kLRIampr5TrP6NhV01k8ZgIS/O0QvoiOt5AbIoszerF
xAWH3uD3o+Xy+GZeOJ3OkHJq3C0rfQX8M5NaYduMyXWpPJRS4+buiSeiTtphilBX
lnNQLNq75PhjTvQnPyUnJ0eAySvV0ZKTW/M8DJn7CT30bbSwRaskY30ku+BnWCsn
Rcsof/28o++n64CNkPGv9Wjuod0OrBM3nlUXPS1eQjHSS/wAQtwZOp4Maa5pHu5+
gNUsBxAasljIqHQRsQPI0js8rfv7E5NZphJBmrXPN2/RpXx5b493MODN1mXdgjWY
hdXw0bx3FrBHnE/XQHtedVKvpksYXvwg7uuJAmEVJGh0guk3fL0VvXyv2dP9eyQa
n9Qx+GRhofHuvd5Mq2bIjGKrVV7pRITMO/We4et4/DmjVb7JvmaiVZbVSzaj60zV
JgF+kN8T3wHorfObJRbX
=4frL
-----END PGP SIGNATURE-----
--=-=-=--