[gmime-devel] Status update on InternetAddress* changes

[Jeffrey Stedfast <fejj novell com>]

I believe I'm now finished with the InternetAddress* API changes on
trunk and I've added a test suite to check that the "changed" event
propagates properly and forces the GMimeMessage to re-sync its To, Cc,
and/or Bcc headers when the corresponding InternetAddressList object (or
any of the addresses it contains) changes in any way.

I should still write an independent test suite for InternetAddressList's
manipulation APIs, but after last night's test suite hackathon, I think
it'll probably be ok now (the header re-sync test suite I wrote used
several of the InternetAddressList manipulation APIs on purpose to serve
as a minimal test suite already, which is how I discovered/fixed some
trivial think-o bugs).

At this point I'm considering removing the
g_mime_message_add_recipients_from_string() API because it is very
unlikely to be used very often (as the developer would need a list of
recipients in encoded string form) and can now be easily implemented
using the InternetAddressList APIs anyway, if a developer ever finds a
need for this.

I'm also now considering making the GMimeContentType and
GMimeContentDisposition objects into real GObjects that will emit a
"changed" event when modified rather than continuing with the current
hack that I have in place. This would also allow
g_mime_object_get_content_type() and get_content_disposition() to return
non-const GObjects for manipulation. Currently, even though they are
const return, the idea was to allow manipulation of said objects - but
that is very confusing with the way things work right now.

Perhaps I need to rethink const-return APIs a bit... it might even be
nice if g_mime_message_get_recipients() /didn't/ return a ref'd object.
If I decide that this is the way forward, then maybe I needn't bother
changing GMimeContentType and GMimeContentDisposition into real GObjects
as they aren't really meant to be shared between multiple GMimeObjects
anyway (it's rare that you'd want to tie 2 mime part's content-types or
dispositions together so tightly, or at least I think so).

Blah... I'll have to audit my current API and see where I use const
return for objects (const return of strings is easy to understand) and
maybe change the rules for objects - e.g. I'll make GMime never return
const for objects, but note that they are not ref'd so if the developer
wants to track the object, he'd have to ref it himself.

More thinking required...

Jeff