allo ben,
ok, again, as this is quite long, let me do a summary:
* i'm again a bit caught out by having to correct some things which it
didn't occur to me that you might not be aware of, apologies for that
- it always catches me off-guard and i don't really know how to handle
it [socially]. so, apologies in advance.
* python's a scripted and dynamic language, and this is GUIs.
a) speed is therefore not a critical consideration
b) the design of pyjamas apps are always ALWAYS single-threaded
c) there IS only ever one profile (hulahop.setup("~/.mozilla/hula")
d) "lazy binding" in pyxpcom takes care of interface changes. we
simply do *not* care.
* there's an entire "cool!" suggestion for an embedded approach, i
won't spoil the surprise by mentioning it here :)
* pyxpcom and hulahop do *not* require any "development": they just
"work". they *only* require "maintenance". the resource allocation
is therefore radically different.
* unit tests and regression tests which can be automated, using
hulahop (and some tricks from the pyjamas-desktop codebase), give the
mozilla foundation an "extra string to the testing bow" of the entire
xulrunner runtime.
On Mon, Feb 27, 2012 at 2:06 PM, Benjamin Smedberg
<[email protected]> wrote:
> 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 question was generic - ok, you got it (the answer's ActiveX), but
you've slightly misunderstood... or perhaps jumped the gun, i'm not
sure which :)
> 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).
yes - you've got it. Microsoft created the (entire!) ActiveX
concept, in order to allow people to be able to embed COM-enabled
controls which conformed to the standard win32 GDI interface into
*any* application.
it didn't - doesn't - matter if that ActiveX component was written 2
or 20 years ago: you grab that DLL (and its associated .tlb) and you
can use it, now and forever.
the reason why i mentioned this was not because the mozilla
foundation created an ActiveX control which installs on the *windows*
platform....
.... i wanted to advocate that the mozilla foundation work with the
free software community to bring about ActiveX-like technology... for
*GNU/Linux* (!) in exactly the same way that it created the
absolutely astounding XPCOM technology.
it's the next logical step.
but if that's too much, then the logical alternative is to rip out
XPCOM and substitute COM for Unix, instead, and then take on some of
the source code from wine [which has had to create a perfect replica
of ActiveX].
don't believe there's
> 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)
yes - that's exactly what hulahop does. what's the problem? there's
only ever one process, and there's absolutely no problem with that.
the reason why in pyjamas-desktop that that's not a problem is
because... ok, *deep breath*, this is going to need some explaining.
when you compile a pyjamas application to run in a web browser, it
runs in the [single-process, no-threaded] javascript context. with
the exception of google's "gears" plugin, javascript execution in
browser engines is *entirely* "one jobbie". this makes life reaaally
easy from a programming perspective: it's a great way to do things.
no mutexes, no shared memory, naaathing.
if you want multiple "things" going on, you do it as timers, as ajax
etc. etc. but even there, only one "thing" can ever be executed (one
timer, one onload event etc.) this is _great_, because it means that
any "complexity" is done server-side. server-side is where you do
multi-processing, multi-threading, use Rabbit-MQ and other
asynchronous blah blah even multiple AJAX queries.
and the fantastic thing about this type of design, which is very
ideally close to the best MVC-like design principles, is that the
responsiveness of the UI front-end is *not* impeded.
it's great, in other words!
now here's the kicker: pyjamas desktop is ABSOLUTELY NO DIFFERENT.
let that sink in for a moment.
in case it's not obvious what the "big deal" is, i'll explicitly tell
you: a pyjamas-desktop back-end using e.g. hulahop *still* uses
nsITimer, *still* even uses nsIXMLHttpRequest, and, critically,
*still* talks to the EXACT same back-end server-side code that the
[javascript-compiled] pyjs version of the application does.
do you see the implications here?
we've just turned a web browser engine into a world-class GUI Widget
Set which *doesn't* suffer from "blocking" on the GUI front-end
because the development paradigm forces developers to follow
close-to-ideal pure MVC design principles.
the bottom line is that there *are* no processes (other that qty 1),
and if anyone actually ever tried to do something like use
g_object_timer or g_threads they would very very quickly run into
serious trouble with race conditions, risk of over-utilisation of CPU
resources and so on _and_ they wouldn't be able to compile the
application to javascript for running in web browsers (because
g_object_timer doesn't exist in web browsers).
the reason i know this is because i tried using g_object_timer in
early versions of the pyjd hulahop port, and yes, i ran into massive
problems :)
so can you see, the requirements are completely different, here, from
anything else you've previously encountered. pyjamas and
pyjamas-desktop is a _mature_ development environment. we've _been_
through the wringer on these issues.
> 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.
yes, i can see that would be the case.
> 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.
this is python. it's a scripted programming language. we don't
care. lazy dispatch, remember?
plus, i *know* that python-comtypes on win32 actually solved this,
gains access to the MSHTML COM Interface, fires up an IWebBrowser2
ActiveX plugin, and gets on with the job.
you remember i mentioned that "lazy dispatch" stuff? each and every
DOM access (function, property) goes via the "named" lookup, each and
every time. i believe it may be cached (in memory) which is part of
the lazy dispatcher's job.
and i _believe_ that mark hammond, who i believe also wrote the
python-comtypes stuff - also made sure that python-xpcom did likewise
[used lazy dispatch].
this is GUI stuff - it's not speed critical. it just has to work,
and it _does_ work. on pythonwebkit (which is a bit different, as it
has direct python bindings, none of this COM/XPCOM stuff
unfortunately), and when using hulahop, _and_ when using COM on win32.
so i know it can be done; i know also that hulahop actually works,
actually does the job - perfectly - for which it was accidentally
designed _way_ beyond what the hulahop creators actually needed it for
(!)
ironic, huh?
>>
>>
>> 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.
ben - hulahop _works_. it doesn't *need* "development", and it
doesn't need shared profile data. one function call -
hulahop.setup("~/.mozilla/hulahopdir") - is all that's needed, and
this has been working - as needed and as designed - since it was
written back in 2006.
all that's needed is for hulahop (and pyxpcom) to be built on the
daily build cycles, and if it breaks, someone tracks down what the
problem is, reverts the commit that broke it until they also create a
patch that updates the code in hulahop (or pyxpcom). and/or makes
damn sure that xulrunner releases *don't* go out the door until
hulahop (and pyxpcom) are patched to work.
the reason for this is because both hulahop and pyxpcom are both
_mature_ products, they're _both_ middleware, and they do *not* need
"development" - just maintenance, to ensure that they're kept
up-to-date with their dependencies (which happen to be mozilla core
libraries unfortunately).
anyway: that aside - apart from hulahop+pyxpcom not being a massive
burden (because they don't need "development", only maintenance),
there really does exist technical development advantages to having a
2nd code-path for regression and unit testing, as that focus-related
bug hints at.
l.
_______________________________________________
dev-embedding mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-embedding
