On 2006-11-27, timeless <[EMAIL PROTECTED]> wrote:
<snip>
> The basic idea of Mozilla2.0 is that just about all rules governing
> Mozilla1.0 can be thrown out. This includes any and all API/ABI
> promises. Note that CAN as defined in RFC 2119 is not the same as MUST
> or SHALL or WILL or anything else remotely definite, it's just CAN.
>
> Anyway, various topics were covered, among them was a conclusion that
> linux distributions in general build all parts of their platform for
> their release from source and thus don't care about ABI between
> versions.
<snip>

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).

Also I feel that Mozilla hasn't been entirely honest with itself about
which APIs are internal and which need to be frozen.  I don't think it's
possible to write a non-trivial embedding application using only the
officially frozen interfaces.  Perhaps there needs to be an intermediate
level of interface stability?

Please:
(1) Ceate a new name and GUID whenever you need to revise an XPCOM
    interface that has ever been exposed.  (This is a basic rule of COM.
    Note that if you don't change the name, this silently changes other
    interfaces that refer to the first changed interface by name.)
(2) Change ABIs infrequently.  (GtkMozEmbed is clearly following this!)
(3) Define SONAME versions for shared objects you build which reflect
    ABI changes.

I recognise (1) is largely outside your remit but please bear this in
mind.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
_______________________________________________
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding

Reply via email to