Re: The future of binary embedding

On 2/25/2012 7:05 AM, [email protected] wrote:
> the first question is this: how the heck is it possible that i could create, in under 3 weeks, an entire port of pyjamas-desktop to use the MSHTML IE engine, *without* requiring access to the proprietary MSHTML Trident Engine?
The browser engine provided by Microsoft has a stable COM API. It also 
does not require the embedder to handle any kind of persistent data 
access: history/cache/cookie stores are handled via a single operating 
system store which is shared across processes.
> the key question is this: what is it about the microsoft technology that makes this possible?  this is not a rhetorical question.  this is not a sarcastic question.  i genuinely require that you actually think, ben, and find out the answer (hint: you already implement one.  or used to.  until it was pulled).
No, we didn't.

The ActiveX control provided an emulation layer which satisifed some of 
the behaviors (allowing gecko to run in a process hidden behind at least 
the basic set of Microsoft interfaces). But because we don't have any 
form of cross-process profile sharing, the embedder either had to 
configure and run their own profile directory (and think about the 
consequences of only being able to use that datastore from one process 
at a time) or run without any data store, which is not a well-tested 
gecko configuration and will cause many websites to fail because cookies 
and the cache do not behave correctly.

In addition, the primary way to access DOM nodes through the MS API is 
via IDispatch, and the bridge between IDispach and COM typeinfo was 
never complete and didn't match the Microsoft implementation in key 
ways. The closest cross-platform equivalent we have to IDispatch is the 
NPRuntime, which is pretty well tested but isn't efficient and has 
inherent cycle issues.
>
> and if microsoft can do it, why can't the mozilla foundation?
We *could* do it. But it would require significant engineering effort to 
implement shared profile data, solve the IDispatch-or-equivalent problem 
(especially if we needed it to be safe for object cycles via the cycle 
collector), and then provide real QA and release resources for the 
project. Since we are not prepared to do any of that at this time, it's 
better to be perfectly clear about the situation then string embedders 
along thinking that they have a better solution than they actually have.

--BDS