as some of you may now, I'm timeless.

i've been involved w/ the mozilla.org projects for a number of years
now, and i've always had an interest in embeddings (and ports, and
portability, and just about everything else...).

as it happens, I recently became the owner of GtkMozEmbed.

I also about the same time visited Mozilla Corporation to discuss plans
for the future (aka Mozilla2.0).

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

One thing that was most definitely not settled is whether each platform
will have its own embedding glue for Mozilla2.0 or whether there will
be a single glue. There are pros and cons to each. But the bottom line
is that any work done today is essentially temporary maintenance on a
dying branch whose end is very near.

Historically GtkMozEmbed, and gecko as a whole promised ABI compat for
anything that was frozen, and GtkMozEmbed being used outside of Gecko
was considered frozen, as such because of the Glib structure design
that it uses, it was not legal to increase the size of the structure to
add more methods or signals.

Because the consumers don't really seem to care about ABI compat and
are more worried about source compat, and because there's really no
good way to improve or change GtkMozEmbed without doing so, we've
decided to break the ABI promise and change the structure size.

The plans for doing so are currently available at
http://wiki.mozilla.org/Gtkmozembed (wikis are wikis, the content may
change or move randomly, possibly to http://developer.mozilla.org/ or
possibly somewhere else similarly unpredictable).

Anyway, I understand that most embedders are not comfortable with
adding more signals, and in fact, I'm probably even less comfortable
with it than any other embedder, but such is life. Today I will land
the current branch (which has been tested and is source compatible with
the major gtk embedders).

dev-embedding mailing list

Reply via email to