david, hi, 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. you 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 properly...] 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 closely at this: http://pyxpcomext.mozdev.org/no_wrap/tutorials/hulahop/xpcom-hulahop.html 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 see any. these lines, for example: # this is equivalent to ~/.firefox profiles subdirectory hulahop.startup('/home/lkcl/test') 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: listener = xpcom.server.WrapObject(ContentInvoker(self), interfaces.nsIDOMEventListener) 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 untenable situation. anyway. i'll try tackling pyxpcom to see if i can get it up-and-running with xulrunner-13. l. _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
