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

[Michael Meeks <michael meeks novell com>]

Hi Harish,

	First - thanks for digging these changes out for me. But - no, I'm not
just interested in ebook (though for OO.o that is all), but I'm
-primarily- interested Evo. itself, in being able to use and test the
most recent version to help avoid regressions, and indeed ship it for
older platforms.

	So - if you could do the same for the other e-d-s libraries, it'd be
great to see what changed there too.

On Fri, 2006-08-11 at 20:03 +0530, Harish Krishnaswamy wrote:
> The changes in question are as follows :
> http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.20&r2=1.21

	So - this changed the EContactPhoto structure - why ? surely that is
rather pointless. You could easily have added an EContactMimePhoto type
and added a synthetic back-compat field that would handle the old case
[ if it was of (whatever) mime type you expected ]. So - I see no
problem at all doing this compatibly whatsoever. Perhaps a few more
(~20) lines of code tops.

> http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.21&r2=1.22

	You converted a gpointer value to a 'const gpointer value' - I don't
see that that is particularly necessary, or likely to break the ABI of
anything unless it reflects some underlying lifecycle issue. Also the
enum insertions were (this time) added at the end of the enumeration, so
why should that break anything ? surely that's a compatible extension.

> This was not a trigger-happy change. 

	I beg to differ.

> The patch for the first bug was submitted on 15 Aug 2005 (almost a year
> ago) and that for the second on 3 Mar 2004 ( more than 2 years ago) and
> had been in the back-burner only because we had wanted to preserve the
> ABI.

	You realise you can *extend* the API/ABI without breaking the ABI
right ?

> The #313533 patch was vital for Ross Burton's dbus-based EDS and running
> EDS on devices (say Nokia 770) would not be possible w/o this change.

	Nonsense - at least the link above has no API change that is necessary
for dbus or Nokia 770 support - unless I'm missing something huge; good
buzz-words though :-)

> The #259536 patch had been blocking a large number of users in Poland
> where Gadu Gadu is the defacto IM standard.

	And doesn't break ABI anyway (AFAICS).

> IMO, a single break after two major releases against such gains is
> justifiable. These patches were reviewed and approved by the addressbook
> hackers before the bump. 

	I'm sure they were reviewed ;-) I'm not debating that.

> Could these improvements have been absorbed w/o breaking the ABI and
> with not too much additional costs in the process?

	Yes - clearly so.

> I do not know - nor did the patch authors or the reviewers. But if you
> could show us, I am all willing to learn.

	Hokay - so - to get the new functionality you require changes on the
client side anyway, so we can ignore that as an issue. e-contact.c
*already* supports 'synthetic' properties [ that duplicate state in
other properties ]. We should have simply added a Photo2 structure [ or
some renamed thing ], changed the name of the property to reflect that,
and updated all callers that cared. [ NB. we had to update all callers
anyway, but with your change, since they using a type-unsafe gobject
property, unchanged callers will SEGV when they call this method ].
While this was being fixed we should have used a GObject for
EContactMimePhoto ( or whatever ) so we could compatibly extend it in
future.

> Can you also help me understand the severity of the break in OO.o ?

	OO.o is one symptom of the huge system-wide problem that you cause for
every application developer foolhardy enough to link against
evolution-data-server. Every user, now who wants to eg. upgrade 'Ekiga'
to the latest version [ across this breakage ] will discover that going
from 1.1.x to 1.2.y he will have to upgrade some huge chunk of his
system - or simply give-up and not test/use the latest version. That is
a horrible idea for anyone - particularly when it's totally unnecessary.

> Why are the library files with SONAMEs hard-coded in a source file ?

	Some applications exist that have to run on whatever is there ? - this
is called being an ISV :-) - Sun is an ISV for Linux, this means a world
of pain [ created by exactly this kind of breakage ]. ie. if OO.o is
going to run on NLD9, and SL10.0, and SL10.1, [ and now SL 10.2 ] how do
you recommend we integrate with evolution-data-server any other way ? -
we -have- to dlopen libraries since they may not be there, and we then
have to try to adapt to whatever breakage they introduced across
versions.

> Why would you not use (say) pkg-config instead ?

	This is not what pkg-config files are for, and anyway:

$ rpm -qf /opt/gnome/lib/pkgconfig/libebook-1.2.pc 
evolution-data-server-devel-1.6.0-43.20

	I'd love to see this change undone ASAP, before code-freeze for Gnome
2.16 is upon us; it's a major bug IMHO.

	Thanks,

		Michael.

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