Re: The future of binary embedding

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