i've got over being taken aback by what you said about the APIs thing,
and it occurred to me that if i didn't provide further information and
explanation there was the risk that people reading my comments could
potentially view the response as being from a "har har i'm more
superior than you har har you're so ignorant har har you know nothing
i know everything now go away and educate yourself" complete fucking
twonce (viz: a twat _and_ a nonce, rolled into one obsequious
egoistical moron whose fingers should be broken to prevent them from
being able to type on the internet, ever again).
as i'm _not_ that kind of person, it's a responsibility and a duty for
me to clarify what i said.
"I think any future in our embedding API should be based around APIs
designed to be an embedding API, not around a collection of internal
functions gathered up and labeled as an API. The problem with the
latter is that it's hard to avoid changing them, because they
weren't designed to be permanent."
the thing is: xpcom isn't an API, it's middleware which *provides*
access to APIs. dynamically. changes to the APIs that are reflected
*through* XPCOM automatically are available.
thus, "XPCOM-the-API" requires no "labelling". it just... is. it
works, it's done. no further development required. that's the nature
of Common Object Models [as long as they've actually been designed
thus also, any APIs that are *available* through XPCOM are *also* "not
your problem". they simply aren't. they're available - transparently
- end of story.
... do you see therefore what i was driving at?
now in addition to that, there's hulahop, which is the "next layer
up", and it's... if you will... "grounding" of both the
XPCOM-accessible NPAPI and the gecko engine into the "reality" of
python from a declarative programming perspective.
look first at the implementation of progresslistener.py. what do you
notice about it? it's nothing more than an object-orientated
"wrapper", in python, around the XPCOM-accessible
nsIWebProgressListener interface, isn't it?
so there _is_ no "API" to be "developed", here, is there?
then, come back to the main hula.py file. what do you notice? what
evidence of the existence of any mozilla-required "APIs" do you see?
what in that file requires any actual API "design"? i honestly cannot
these lines, for example:
# this is equivalent to ~/.firefox profiles subdirectory
they are absolutely essential. there's no "design" required. ok,
perhaps you might pick a different name from "startup", but who
honestly cares about that?
then there's the ContentInvoker class. this is required as part of
the XPCOM API, which is set in stone, is not going to change. the
invocation and linking of ContentInvoker class instances is, again,
set in stone:
so that is inviolate, as well. no API development required.
the class Browser, which derives from the c-based python-gtk module
"WebView", is where there *might* be room for "API Development", but
there you're actually actively constrained by the _GTK_ API, or more
specifically by the python-gtk2 API, which defines how pygtk widget
APIs are written.
so absolutely no "development" of "APIs" is required *there*, either.
about the only function which looks slightly odd, to me, is this
"do_setup" function. i don't actually know the deep compelling
technical reason why that's there, and i mention that in the tutorial.
looking in the source code hulahop.c it's _still_ not blindingly
obvious, but i'm not going to worry about it. the main point is: it
appears to be a techical detail associated with the fundamentals of
python c-based modules, getting over some problem/issue that the
hulahop developers created, and, again, it has absolutely nothing to
do with xulrunner "APIs".
conceivably you could argue that the name of this function "do_setup"
could be changed, but what would be the point?
so, throughout the entire hulahop codebase there is nothing -
absolutely not one single thing - that requires "designing". the
hybrid combination of the various bits of technology *automatically*
defines the published and public API.
you create a widget, you get access to the NPAPI. wow! that's so
simple, it's actually difficult to make it complicated enough for
people to grasp the significance.
so do you see? not only is there no API designing required, but there
exists proven stable code that already *implements* the
already-automatically-technically-constrained "API". code which, if
you even tried to modify it would result in yet further (and
unnecessary) knock-on effects for the users of that code in an already
anyway. i'll try tackling pyxpcom to see if i can get it
up-and-running with xulrunner-13.