Ben Hutchings wrote:
Speaking as a Debian developer who embeds Mozilla, I disagree with this.
Yes, we build everything from source. However do not want to have to
rebuild every package that uses Mozilla every time Mozilla changes, and
especially not for security fixes (since this will delay availability of
fixed packages).
I might have misunderstood the point of the Mozilla 2.0 discussion, but as I
understood it the idea was that Gecko 2.0 might not be ABI-compatible with Gecko
1.x, including frozen Gecko 1.x interfaces. At that point there would be a new
ABI which I would certainly hope we would preserve to some extent and
_definitely_ preserve on stable branches.
Also I feel that Mozilla hasn't been entirely honest with itself about
which APIs are internal and which need to be frozen.
Oh, we've been honest with ourselves. We know the situation is in a crap state.
We just haven't had the manpower to make it better. More to the point,
designing freezing interfaces is not something people are likely to volunteer
for, and no one's been willing to pay people to do it.
I don't think it's possible to write a non-trivial embedding application using
only the
officially frozen interfaces.
No thinking needed -- it's not possible. In fact, I doubt it's possible to
write a trivial one, given that nsIWebNavigation and nsIBaseWindow are not frozen.
Perhaps there needs to be an intermediate level of interface stability?
There effectively has been... We've been treating nsIWebNavigation as
effectively frozen, even though the documentation is not good enough to actually
freeze it.
(1) Ceate a new name and GUID whenever you need to revise an XPCOM
interface that has ever been exposed.
Since all XPCOM interfaces are "exposed" the moment you check them into CVS and
allow instantiation of the object in any way, this basically amounts to the
requirement that any time an interface is changed its name change (and that the
old interface always be around). In other words, all interfaces are to start
frozen on initial checkin. That's not really feasible. We do change the GUID
every time the interface changes, to prevent issues with incorrect vtables.
There's also the question of what constitutes an "XPCOM interface". There are
some things that look a lot like "XPCOM interfaces" that really aren't
(nsIDocument comes to mind). We've been working on deCOMifying these as needed,
but the fact of the matter is that we have some need of Gecko modules to be able
to talk to each other. We use interfaces for this purpose. Often, no one by
Gecko internals should be using these interfaces, and we do not promise any sort
of compat for them. We're happy to mark these interfaces as private in the
interface documentation, if that would help. Of course public versions of these
should be available if needed (e.g. compare nsIWebNavigation and nsIDocShell).
Note that if you don't change the name, this silently changes other
interfaces that refer to the first changed interface by name.)
Yes, this is why we require that all interfaces referred to by nsIFoo be frozen
before nsIFoo can be frozen.
(2) Change ABIs infrequently. (GtkMozEmbed is clearly following this!)
I'm not sure what exactly you lump under "ABI" here (the way an interface IDL
file is mapped into a vtable? Or particular vtables for particular interfaces?
The former doesn't change much at all, until now; the point is that with Gecko
2 it will change).
(3) Define SONAME versions for shared objects you build which reflect
ABI changes.
I'm not going to touch this one; you and bsmebderg should sort it out. ;)
-Boris
_______________________________________________
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
