On 2/25/2012 3:53 AM, [email protected] wrote:
We never solved it fully, and each embedder has had to
spend lots of time tweaking things.
perhaps it might be worthwhile for the mozilla foundation to find - and fund
- the people who _do_ understand these things, rather than totally abandon
existing efforts and leave entire communities completely without support:
http://lists.sugarlabs.org/archive/sugar-devel/2011-June/031865.html
There is no free lunch. As I noted, finding and funding embedding
support must necessarily come at the expense of something we could be
doing instead. Overall I'm not saying that we don't want Mozilla to be
embeddable, but that there are more important things to work on, both
strategically and technically. This is not a permanent calculus, and it
can change again in the future.
Part of this decision is merely making clear that there hasn't been a
community maintaining this code effectively. If you'd like to build that
community, I encourage you to do so!
no it's not. if you have things like XPCOM which is a dynamic "object model"
interface, you don't *need* "binary compatibility" - you just need to make sure that
XPCOM works.
XPCOM, which was based on (inspired by) microsoft's COM, is just as
misunderstood, it seems, as COM is.
the benefits of Common Object Model technology are just... i cannot emphasise
enough how powerful they are. this is something that the Free Software
Community as a whole simply does NOT get, to its detriment. microsoft
dominated computing for nearly two decades thanks to COM/DCOM. apple dominates
its sector through Objective-C, at the heart of which is, yes, you guessed it:
a type of Dynamic Object Model system.
objective-c and COM are fundamentally different in how they achieve
backwards compatibility. XPCOM "working" correctly will prevent you from
crashing, but it only achieves the goal of being *compatible* if you
don't change the interfaces. We have tried this, and it's clear that our
current interfaces are not suited to freezing. The XPCOM object model in
gecko does not suit the needs of binary compatibility.
We are focused primarily on the *script* compatibility, and to the
extent that we want a good embedding API in the future, it will be
designed around embedding via script, and primarily JavaScript since
that is the language of the web. We do make strong compatibility
guarantees for JS, and we should be able to do that for embedders as well.
so do you think it would be a good start for the mozilla foundation to
adopt python-hulahop as the beginnings of reversing this trend towards
isolation of the mozilla foundation from absolutely everything but
javascript, javascript, javascript and firefox, firefox, firefox?
What kind of "adoption"? I don't think that python-hulahop is
strategically important to our core goals of innovation on the internet.
So I don't think that in terms of the Mozilla mission our core community
should make maintenance and development of that code a priority. I'd be
happy to provide a place for you or somebody else to build a community
around python-hulahop, though.
--BDS
_______________________________________________
dev-embedding mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-embedding
