Re: [Evolution-hackers] More e-d-s ABI breakage ?

[Michael Meeks <michael meeks novell com>]

Hi Ross,

On Fri, 2006-08-11 at 17:32 +0100, Ross Burton wrote:
> The change was required for the 770 as ferrying the photos over the bus

	Sure - I like the core change, but not the API/ABI detail :-)

> If it's required it might be possible to revert that change and
> introduce an alternative.  As you say, a "photo2" property that returns
> a new type should be sufficient, I'll have a look later.

	Sure, although of course it may be more complex than that; this was a
1st glance review.

> I have Grand Plans to write a replacement for EVCard and EContact
> though.  I've been adding new API to e-vcard to make it more usable, but
> that is just complicating the API for no gain.  Extending EContact is a
> pain as all of the data types are public structs with no padding.

	Sounds lovely. From an OO.o perspective we want a thread-safe 'cursor /
iterator' API ;-) as in:

	for (line = do_query_get_1st; line; line = line->getnext()) {
		...
	}

	but I guess we handle all our async stuff via threads.

> EContact also manages to hit that sweet spot between
> complicated-but-powerful and easy-but-limited, so it's
> complicated-and-limited at once.

	Heh ;-) I'm sure there are (no doubt) tons of problems with the API -
however, a drip, drip of incompatible breakage is no solution IMHO.
Clearly building your nice new API in parallel, deprecating the old API,
and [ in a few versions time ] doing a big bang switch to the new (by
now perfect, tested, GObject based, extensible etc. ;-) API seems a
better approach. Hopefully we can write an 'evoab3' connector to it
then.

	All the best,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot