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.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
_______________________________________________
Evolution-hackers mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/evolution-hackers
