Proposals for 3.0.0 API changes

[Gary Kramlich]

Richard Laager wrote:
> On Sun, 2007-12-30 at 22:02 -0500, John Bailey wrote:
>> In the msn-pecan thread, Gary and I agreed that an API freeze after 2.4.0 in
>> order to implement struct member hiding would be a good way to help us on the
>> road to having libpurple's objects implemented purely as GObjects.  Ka-Hing
>> voiced support for the proposal.
> 
> I'm not necessarily opposed to this, and I think it'd be great for
> things (as I mentioned in my other e-mail here).
> 
> That said, I'd like to suggest an alternative for discussion:
> 
> "Struct member hiding" means moving the struct definitions from the .h
> files to the .c files, correct? What if we did the following:
> 
> For each struct:
> 
> 	1. Copy the struct definition into the .c file and wrap it with #ifdef
> PURPLE_HIDE_STRUCTS.
> 
> 	2. Wrap the struct definition in the .h file with #ifndef
> PURPLE_HIDE_STRUCTS.
> 
> 	3. Compile with CFLAGS=-DPURPLE_HIDE_STRUCTS and fix up references to
> that struct?
> 
> Alternatively, we could use PURPLE_DISABLE_DEPRECATED there or make it
> imply PURPLE_HIDE_STRUCTS.
> 
> If we did that, we could do the struct hiding one struct at a time on a
> branch and then propagate to trunk as we went. It wouldn't break API
> compatibility because the public headers would have the definitions by
> default.

This is doable, but we have to add a TON of accessor API per object.
Which of course, means a minor bump each time.  So we do what 4 objects,
bump the minor, release, do X more, bump the minor release, etc?

> Once the struct definitions were fixed, it'd be much easier to do the
> GObjectification. We could do that on a branch and when it was done,
> release it as 3.0.0 with all the deprecated stuff dropped.

The problem isn't just the struct hiding.  The struct hiding just makes
it easier to compile after objectifying.  However, working against a
moving target, and having to constantly merge everything back up is the
real killer right now.

Mind you this wouldn't be that bad if I could keep up on it.  But
consider this scenario.  I have all of the Cipher stuff done on
i.o.gobjectification.  The new des stuff and hmac stuff needs to know
get added to all of this.  This are the moving changes I'm talking about.

Also, since I've updated the prpls to use the new cipher objects, once a
single line is changed in there, it seems like I'm merging that was
well.  These are the moving target issues that make merging absolute hell.

> Richard

-- 
Gary Kramlich <grim at reaperworld.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080102/9d001b6e/attachment.sig>