Re: The future of binary embedding
Does anyone have an idea about how much work it would take to maintain python-xpcom? Lots. I don't know much about pyxpcom, but I imagine it being pretty analogous to XPConnect (our JS-XPCOM bridge). XPConnect is probably the most notorious module in Gecko - it's complicated, scary, and easy to get wrong. We already sink a ton of engineering resources into it, and wouldn't if it weren't so fundamental to our entire architecture. More importantly, for a number of reasons the DOM is becoming more intimately tied to JS: we're removing the abstraction layer that sorta-kinda makes the DOM language-agnostic (it's too slow), and we're writing new custom DOM bindings. So if it isn't true already, pyxpcom won't be able to script the DOM anymore, which makes it significantly less useful. Reversing this course (and maintaining a separate set of python DOM bindings) is pretty much out of the question: it incurs a performance penalty for the Web that we don't want to pay, and it would take months and months of engineering by Boris, Kyle, Peter, Blake, Ben, Johnny, Olli, and myself to make happen. In a nutshell, script bindings aren't easy - this stuff is some of the most complicated and delicate code in Gecko. So the issue isn't that Benjamin is too lazy or proud to keep the relevant embedding APIs. The issue is that there is a very small group of people in the world who have the knowledge to build and maintain something like this, and they have other priorities. bholley ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
https://bugzilla.mozilla.org/show_bug.cgi?id=731121 where is the information required to fix this problem? also, why was pyxpcom excluded from the update my god this was _months_ ago! https://bugzilla.mozilla.org/show_bug.cgi?id=675221 why was pyxpcom not included in that update, when the information was fresh in everyone's minds?? oh i know - because pyxpcom has been relegated to third party status. ok. how is this going to get fixed? (a so that this stops happening b these specific coding errors so i can get some working code) On Tue, Feb 28, 2012 at 6:05 AM, lkcl luke luke.leigh...@gmail.com wrote: the policy of relegating pyxpcom to third party status within the mozilla codebase has resulted in these kinds of things, below. you will recognise this as the consequences of a decision some time in the past few weeks (which i wasn't party to, because i am an outsider having no funds or time to pay 24x7 attention to each and every decision made by the people who _are_ funded by the mozilla foundation) basically that decision looks like it involved deliberate splitting of the header files into public api and not public api. so, this header file nsIProxyObjectManager.h is treated as internal api... ... but somebody forgot that pyxpcom needs it... because they have relegated pyxpcom to third party status. they forgot that pyxpcom *needs* to be built as an internal component, yet the mozilla foundation has completely failed to provide a system for building such components, yet at the same time has basically dumped the responsibility onto other people. if however pyxpcom was actually part of mozilla-central, then not only would this problem simply not be present but also it would be a damn sight easier to find issues. temporarily i am forced to manually seek out, copy and make available this nsIProxyObjectManager.h file each and every damn time i do a rebuild and reinstall of a particular version of the xulrunner runtime. that's incredibly tiresome and it's part of the *additional* burden that the mozilla foundation's decisions are placing onto external developers. ... developers that are *not* funded by the mozilla foundation, it's worth once again pointing out. right now i cannot agree more that the OLPC team made the right decision to remove all mozilla-foundation-funded technology from their machines. l. c++ -o _xpcom.o -c -I../../../dist/system_wrappers -include ../../../../config/gcc_hidden.h -DOSTYPE=\Linux2.6\ -DOSARCH=Linux -DMOZ_NO_MOZALLOC -I/usr/include/python2.7 -I../../../../xpcom/src/module -I. -I../../../dist/include -I../../../dist/include/nsprpub -I/usr/local/lib/xulrunner-devel-13.0a1/include -I/usr/local/lib/xulrunner-devel-13.0a1/include/nsprpub -I/usr/include/nspr -fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -DXULRUNNER_13_0A1 -std=gnu++0x -fshort-wchar -fno-strict-aliasing -pipe -std=gnu++0x -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions -DMOZILLA_CLIENT -include /usr/local/lib/xulrunner-devel-13.0a1/include/mozilla-config.h -Wp,-MD,.deps/_xpcom.pp ../../../../xpcom/src/module/_xpcom.cpp ../../../../xpcom/src/module/_xpcom.cpp:68:35: fatal error: nsIProxyObjectManager.h: No such file or directory compilation terminated. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On Wed, Feb 29, 2012 at 4:30 PM, lkcl luke luke.leigh...@gmail.com wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=731121 oh i know - because pyxpcom has been relegated to third party status. Yes, exactly. how is this going to get fixed? (a so that this stops happening b these specific coding errors so i can get some working code) It's not going to get fixed unless someone steps up to fix it. And as has been stated several times, the core Mozilla community has no interest in doing so. - Kyle ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On Thu, Mar 1, 2012 at 2:29 AM, Justin Lebar justin.le...@gmail.com wrote: i'm going to keep on, and on, and on, and on, and on, and on at this until i get answers, and pyxpcom works. Luke, I think it is unlikely that you will accomplish your goals if you make trolling your primary strategy. i don't know what trolling is, and you are probably mistaking trolling for pathological bug-fixing and 100% focus on getting a goal completed irrespective of trying to make friends. but you are dragging the conversation off topic. i am still waiting for ben to acknowledge the points made regarding his misunderstanding of the situation regarding the continuous changes to XPCOM interfaces, which are absolutely irrelevant to dynamic programming languages. and, if that was the primary justification for destroying pyxpcom then it is a mistake. You've tried to argue that it's in our best interests to maintain the python-xpcom bindings. Those in this thread have heard your argument, no they haven't. i'm not done yet. there's more to this. so far i've explained to chris that javascript as a compiler target of a dynamic programming language results in an order of magniture performance hit; to ben that he's mistaken about the binary compatibility issue and so on. and they disagree. how can you disagree with an incomplete perspective? i don't understand. You think that's our loss, and maybe you're right! maybe? there shouldn't be *any* maybe. you're supposed to be world leaders at the forefront of technology. there should _be_ no maybes. But just because you think we're wrong doesn't give you the right to waste everyone's time. You are not entitled to anyone's attention here or in bugzilla. you are assuming that this is ego-driven. where is the money that i am being paid to do this work on behalf of others? where is it? can you please tell me where the personal motivation is, please? have you seen any? mm? you've already badly let down the OLPC community. that means that it's now my responsibility to the pyjamas community to get this done, and i'm PISSED that it's going to cost _me_ money and time when i've been earning UNDER POVERTY LEVEL INCOME FOR FOUR FUCKING YEARS. do you not fucking get it? we got EVICTED last year - myself, my partner and my 2-year-old daughter, because i stick to free software principles and have to turn down lucrative contracts where people in the United States violate the Treaty of Rome's clauses on intellectual property ownership. you guys have absolutely no idea. i was _homeless_ for two years, from about 2007 to 2009 for god's sake. and i _still_ kept to free software principles and still kept working on free software. Maintaining xpcom bindings for Python is work! You're probably right that it would be more work for you than it would be for a core xpcom contributor. But it's work either way, yes, it is. so go on. ban me. come on. go stick your fingers in your ears. make the decision to revoke my bugzilla account (like the webkit team did, after their deliberate bullying). see how far that gets you. the damage to the free software community of mark rowe's bullying was - is - _immense_. you want to do the same thing? go ahead. because if you don't start taking responsibility for this instead of going nur, nur it's not our core focus, i _will_ absolutely pathologically drive you to that. and I think you are unlikely to convince someone to do work by threatening to be a troll. i don't actually know what a troll is. however i _will_ be absolutely pathological, persistent and get this done. it would be very very good if you found someone _else_ to do the work. anyway. you've made me extremely angry, but let's forget that that happened, shall we? now, back to the subject at hand. here's where we are: i'm waiting for ben to acknowledge that the points made about the dynamic programming language bindings to XPCOM interfaces make no odds regarding this binary compatibility argument. he very kindly raised the point, which gives us an insight into why the mistake was made. now. ben. without prejudice. it's okay to admit that you made a mistake. nobody is going to think anything less of you if you say ah, i made an error of judgement because i didn't know how pyxpcom+hulahop works do you acknowledge that for dynamic programming languages which use lazy binding, binary compatibility with XPCOM interfaces is irrelevant? i'm keenly aware that all decisions have been made to destroy pyxpcom based on the mistaken assumption that binary compatibility is important to dynamic programming languages. a simple yes would suffice, then we can move on to the next stage, ok? l. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On 2/27/2012 1:14 PM, lkcl luke wrote: btw, ben, about speed of using XPCOM through pyxpcom+hulahop... Luke, it seems like you've ignored a very important reply to your ongoing attempts at educating Mozillians about the value of your project. I urge you to re-read what Benjamin said in a previous reply: 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. - A ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On 2/25/2012 7:05 AM, luke.leigh...@gmail.com 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 ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
allo ben, thanks for taking this up. On Mon, Feb 27, 2012 at 1:53 PM, Benjamin Smedberg benja...@smedbergs.us wrote: On 2/25/2012 3:53 AM, luke.leigh...@gmail.com 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! well... there's the problem. there's a community *depending* on this stuff *working*, but they are all python programmers. they shouldn't _have_ to learn c or c++ - massive amounts of it. and, because this code doesn't actually need development - just maintenance - there's no community to actually build! there's a critical CRITICAL difference between middleware and the code that *uses* that middleware. the maintenance and development cycles are _completely_ different. * code that uses middleware requires continuous upkeep, development etc. in order to stay relevant. it's also orders of magnitude larger than the middleware it uses * middleware does NOT require constant development. it works or it doesn't. if it doesn't work, it was designed WRONG in the first place. middleware DOES however require maintenance to keep up-to-date with its dependencies (mozilla-core in this case). ... how can a community be built around something that requires only a tiny amount of occasional maintenance? ... it can't, can it? once every year to two years, a couple of hard-core developers get together, bash out a few updates on the dependencies, and then go away again? that's *not* a community, is it, ben. you see what i'm getting at? just because xpcom (and hulahop) appear not to have an active community does *not* mean that they are shit or unmaintained or should be relegated to third party status or removed entirely from the mozilla codebase. that's the mistake that's been made. 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. ah in static programming languages, yes. in dynamic programming languages such as python where you use the trick of lazy / dynamic binding (based on the name) - absolutely NOT. the changing of the interfaces is COMPLETELY irrelevant. We have tried this, and it's clear that our current interfaces are not suited to freezing. ben - python doesn't *care* about the interface GUIDs, and as long as the interfaces are designed by adding extra default arguments (rather than changing the number or order of the arguments), python doesn't even care if you _add_ to the interfaces. even if you change the type of one of the arguments from say a nsHTMLImage to a nsHTMLElement python *still* doesn't care! this is really really frustrating for me to have to be explaining this stuff because you should _know_ how it works. but there's more. do you remember this bugreport? https://bugzilla.mozilla.org/show_bug.cgi?id=502234 do you remember that i said that adding that optional_arg concept was a really bad idea [instead of doing proper IDispatch (coclass) stuff where you can merge / look up multiple COM interfaces]? the reason for that is clear when you look at microsoft's COM IDL files for MSHTML. you don't need to look at _microsoft's_ COM IDL file(s), you can look on the Wine web site, here: http://source.winehq.org/source/include/mshtml.idl
Re: The future of binary embedding
On Sat, Feb 25, 2012 at 4:59 PM, L. David Baron dba...@dbaron.org wrote: Has PyXPCOM been hooked up to the cycle collector yet, or do uses of APIs that depend on cycle collection just leak memory? david, hi, this had me thinking again. pyxpcom was designed, eek... a decade ago? but i'm not sure it's entirely relevant. the logic goes as follows: * python objects (in c) have their own obj-ref count concept * XPCOM objects also have their own obj-ref count concept (AddRef) which is exactly the same as COM, which inspired XPCOM. * when a python object corresponding to an XPCOM object is created, python takes care of adding *one* and *only* one XPCOM object into the c data structure, and calls AddRef *once* and *only* once. * also at the same time, the python object has its PyObject_Ref increased (by one, obviously). * when you need that exact same XPCOM object, if mark hammond didn't program a way to look up the python object which was *already* created to look after it, i'll fall off my bloody chair. * so, assuming that mark is the competent programmer that he is, when you look up an XPCOM object for which a python object already exists, you DO NOT increase the refcount (AddRef) on the XPCOM object, you increase the refcount on the *PYTHON* object. * when the python object's refcount goes to zero, *python's* garbage-collection takes care of destroying the python object, and in the destructor function (in the c-based pyxpcom module), that code also performs an XPCOM Release call. so with this in mind, i do not see how the cycle collector has any relevance, because pyxpcom is merely a direct reflector of the XPCOM objects. but i believe that todd would welcome some input - to todd, who is the de-facto maintainer of pyxpcom - because he, as the de-facto maintainer, would be the person with the most experience in actually sorting it out. esp. if it's a global function that, if not called, results in XPCOM objects not getting properly garbage-collected after the Release or something - i don't know, because i don't know what this cycle collector is, or what it does. just fyi i went through some... interesting times with webkit's memory management. they don't have anything like XPCOM: it's entirely c++ classes. a massive suite of virtual base classes that derive from a class named DOMObject. mostly :) at the ultimate lowest level they had to implement the usual type id system which lets you externally identify an object even when it's type-cast back down to the absolute lowest object in the hierarchy (gobject has something similar, except they do it entirely in c!). XPCOM and COM both have something similar, except they drop a GUID into the type field. this type id allows you to *BACK*-typecast a c++ object up to its correct (real) class! on top of this, they have c++ refcounting (virtual base class, again). as the concept of XPCOM / COM was entirely missing, they have a templated infrastructure which allows you to map object-of-the-bound-type to object-of-the-webkit-type-when-typecast-down-to-the-base-class-type. then you have to _manually_ provide a massive suite of upcast functions which check the type-id and call the next upcast function in the chain, after doing a switch statement to get there! all this to handle the one-for-one representation between (say) python objects and webkit's c++ objects, or gobjects and webkit's c++ objects. but even here, you can _still_ do and only need to do one and only one refcount increase on a per-object basis, because once you've gotten into the other side (the bindings), the refcounting of *that* system takes over. so there are close parallels - it's still complicated as hell though :) anyway, do let todd know about this cycle collection because i have no idea if he knows about it. l. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
btw, ben, about speed of using XPCOM through pyxpcom+hulahop... when i said we don't care [because working is a higher priority than speed, and it's a GUI anyway], i think it helps to give some context. for the pyjs (compiled) version of any pyjamas application, the fact that python is a dynamic language, being translated to another dynamic language, gives a performance hit that's so high it's difficult for people to believe it could be that bad, just to obtain python feature interoperability. [with the end result that they go off and implement their *own* python-to-javascript compiler, in some cases. this has actually happened about four times, now!] i spoke about this on b2g a couple of months back, when chris jones (bless him) rather naively said that javascript was acceptable as the de-facto language of the web implication being in absolutely all circumstances because of projects such as dart, gwt and pyjamas. if he'd ever run pyjs he'd've known that that simply isn't true, because to even do something as simple as use the add operator, you must check first if the two objects being added actually exist - which must be done dynamically in case __getattr__ has to be used; then you have to check the type of both objects (int? float? string?) and go through a lookup table (!!) to find out if the two are compatible; then you must coerce one type to the other; then _finally_ you can actually add the two objects. that very _very_ small and i mean small description should have you going oops... and it should emphasise that maybe javascript as a compiler target isn't such a good idea after all - not for dynamic languages, anyway. by contrast: for _static_ programming languages like java, c and c++, it's great! but for pyjamas, the performance hit is so high that when you run the exact same application under pyjd it's a five-fold performance improvement. against that kind of background, and bearing in mind that that's still using name-based lookups for absolutely each and every single access to absolutely every single one of the functions, objects and properties of DOM/HTML5, what we have right now looks very very good. speed's *not* critical. we're using xulrunner+xpcom+hulahop as a GUI widget set. a very powerful and flexible one. pyjd doesn't have to be lightning-quick. i've installed it on 400mhz ARM9 CPUs, and it had perfectly acceptable performance. l. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
the policy of relegating pyxpcom to third party status within the mozilla codebase has resulted in these kinds of things, below. you will recognise this as the consequences of a decision some time in the past few weeks (which i wasn't party to, because i am an outsider having no funds or time to pay 24x7 attention to each and every decision made by the people who _are_ funded by the mozilla foundation) basically that decision looks like it involved deliberate splitting of the header files into public api and not public api. so, this header file nsIProxyObjectManager.h is treated as internal api... ... but somebody forgot that pyxpcom needs it... because they have relegated pyxpcom to third party status. they forgot that pyxpcom *needs* to be built as an internal component, yet the mozilla foundation has completely failed to provide a system for building such components, yet at the same time has basically dumped the responsibility onto other people. if however pyxpcom was actually part of mozilla-central, then not only would this problem simply not be present but also it would be a damn sight easier to find issues. temporarily i am forced to manually seek out, copy and make available this nsIProxyObjectManager.h file each and every damn time i do a rebuild and reinstall of a particular version of the xulrunner runtime. that's incredibly tiresome and it's part of the *additional* burden that the mozilla foundation's decisions are placing onto external developers. ... developers that are *not* funded by the mozilla foundation, it's worth once again pointing out. right now i cannot agree more that the OLPC team made the right decision to remove all mozilla-foundation-funded technology from their machines. l. c++ -o _xpcom.o -c -I../../../dist/system_wrappers -include ../../../../config/gcc_hidden.h -DOSTYPE=\Linux2.6\ -DOSARCH=Linux -DMOZ_NO_MOZALLOC -I/usr/include/python2.7 -I../../../../xpcom/src/module -I. -I../../../dist/include -I../../../dist/include/nsprpub -I/usr/local/lib/xulrunner-devel-13.0a1/include -I/usr/local/lib/xulrunner-devel-13.0a1/include/nsprpub -I/usr/include/nspr -fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -DXULRUNNER_13_0A1 -std=gnu++0x -fshort-wchar -fno-strict-aliasing -pipe -std=gnu++0x -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions-DMOZILLA_CLIENT -include /usr/local/lib/xulrunner-devel-13.0a1/include/mozilla-config.h -Wp,-MD,.deps/_xpcom.pp ../../../../xpcom/src/module/_xpcom.cpp ../../../../xpcom/src/module/_xpcom.cpp:68:35: fatal error: nsIProxyObjectManager.h: No such file or directory compilation terminated. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
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
Re: The future of binary embedding
On Monday, March 28, 2011 10:03:11 PM UTC+1, Benjamin Smedberg wrote: Last summer, I led a session at the Mozilla summit to discuss whether and how we ought to continue supporting our various embedding efforts (gtkmozembed, javaxpcom, the ActiveX control, the NSView embedding widget, etc) given the effort involved in preserving their various degrees of code and binary compatibility with Mozilla core. We came the following conclusions: * Embedding Mozilla rendering into other processes is a tough problem. no it's not - the python-hulahop widget uses GTK just like firefox does: it works perfectly, and it even provides access to XPCOM so that python-xpcom can get hold of the NPAPI and use DOM functionality in exactly the same way that javascript does [when xulrunner is embedded in firefox] 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 * Firefox is the key product of the Mozilla project; to the extent that supporting embedding takes away from Firefox, we should strongly prioritize Firefox. * Binary compatibility of our embedding bindings is a high cost 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. which is not worth the benefits. what??? completely abandoning and orphaning entire communities is seen as beneficial?? * As we move Firefox into a multiple-process model, the embedding solution we really want is very different from the one we currently have: we really want embedders to be simple containers for a separate Firefox process which would do the actual web rendering. Because of this, I'm planning on making the following changes in our code: * Remove gtkmozembed and its supporting code. that's actually very sensible. gtkmozembed is pretty lame. it doesn't go nearly far enough. without dynamic language bindings - i.e. without access to what's actually *in* the web page, who the hell just wants to drop a web rendering engine into an application? you didn't go far *enough*, ben. people want to be able to drop in widgets into the middle of the HTML page: they want to be able to respond interactively to events (DOM events) - but not just in c, it has to happen in *all* programming languages, be it c, c++, java, python, ruby, perl - anything. now. that *is* possible with python-hulahop. 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? The promise of gtkmozembed was a binary-compatible wrapper that GTK applications could use to easily get web rendering into their application. Without significant supporting code to deal with profiles, certificates, prompts, and other details, this code doesn't work correctly, and is unmaintained. hulahop manages absolutely fine. all that's written in python. it just works. As a project, we aren't going to spend effort trying to solve the problems associated with in-process embedding. Once separate-process rendering is implemented in Firefox, we may consider ways to make really simple multi-process embedding a possibility. it's not enough. you need to have the dual worlds functionality. a foot in the embedded widget door *and* a foot in the DOM world, via XPCOM. hulahop provides exactly that. the problem is that because it's third party, it's absolute hell for non-funded part-time free software community members to keep it up-to-date, and the mozilla-foundation-driven release cycle does *not* include hulahop, meaning that releases like xulrunner 10.0.2 go out the door with serious memory corruption problems that, more by luck than judgement, happen *not* to be hit by firefox... but that hulahop runs smack into with a segfault. what is the mozilla
Re: The future of binary embedding
ben, there's a line of questioning that i'd like to engage you on. please could you review the pyjd/mshtml.py code, which you can find here: http://pyjs.org/pygit/ 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? and, how come that pyjd MSHTML port works, without fail, utterly flawlessly, with the exact same MSHTML engine from IE6, IE7, IE8 _and_ IE9, and i have reasonable confidence that it will continue to work without fail, without modifications required, on *all* future versions of the MSHTML Trident Engine. 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). and if microsoft can do it, why can't the mozilla foundation? more questions once you've answered the key question. l. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On Sat, Feb 25, 2012 at 4:59 PM, L. David Baron dba...@dbaron.org wrote: On Saturday 2012-02-25 00:53 -0800, luke.leigh...@gmail.com wrote: On Monday, March 28, 2011 10:03:11 PM UTC+1, Benjamin Smedberg wrote: * Embedding Mozilla rendering into other processes is a tough problem. no it's not - the python-hulahop widget uses GTK just like firefox does: it works perfectly, and it even provides access to XPCOM so that python-xpcom can get hold of the NPAPI and use DOM functionality in exactly the same way that javascript does [when xulrunner is embedded in firefox] Has PyXPCOM been hooked up to the cycle collector yet, or do uses of APIs that depend on cycle collection just leak memory? david, thank you for responding on this. ... now, you see... this kind of information is entirely missing - and it's the relegation of pyxpcom to third party status within mozilla's project management - i.e. its removal from mozilla-central - that results in things like that massive PRBool-bool substitution, and other straightforward maintenance, being entirely missed. so the code is just left to rot, or is left to someone who really doesn't have the time or resources to focus 100% on keeping absolutely without fail without exception absolutely 100% up-to-date with every single one of the advances and modifications made to the mozilla core codebase such that they even *know* about things like the cycle collector. now, as it's a small codebase, i'm certain that someone who *does* know about this cycle collector, or any other code modifications, could probably bring pyxpcom up-to-date prior to each xulrunner stable release in very short order, especially when working alongside someone like todd who is familiar with the code. ... but the fact that nobody has even bothered, and has pretty much abandoned the code, leaves it as worse than useless, and a massive drain on the time and resources of the free software community, who have to learn or re-learn about each and every single API change, each and every single mozilla core codebase change each and every monotonous time *right* before a release. that's massively unfair to expect members of the free software community to do. hence why i have requested - formally on mozilla.governance - for advice on how to go about making a formal request that the mozilla foundation a) adopt python-hulahop as a 1st level priority project b) reinstate pyxpcom as a 1st level priority project - preferably *back* into mozilla-central. c) introduce unit tests that, if not passed, will block the release of *any* xulrunner release at the time until such time as the bugs are fixed and the unit tests pass. the end result will actually be an *improvement* in the quality of the xulrunner and the firefox codebase because it will result in a different kind of testing - from a different angle with different code-paths of the exact same core components that are utilised in firefox. do you happen to know to whom such formal requests should be directed? many thanks, l. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On Saturday 2012-02-25 19:38 +, lkcl luke wrote: now, as it's a small codebase, i'm certain that someone who *does* know about this cycle collector, or any other code modifications, could probably bring pyxpcom up-to-date prior to each xulrunner stable release in very short order, especially when working alongside someone like todd who is familiar with the code. It's not. It's a massive task. (I'd guess it's roughly equivalent in complexity to everything else in PyXPCOM. That is, I'd guess that this would be about half the work of writing PyXPCOM from scratch with it included. That's a very rough guess, though.) ... but the fact that nobody has even bothered, and has pretty much abandoned the code, leaves it as worse than useless, and a massive drain on the time and resources of the free software community, who have to learn or re-learn about each and every single API change, each and every single mozilla core codebase change each and every monotonous time *right* before a release. that's massively unfair to expect members of the free software community to do. Why do you consider Mozilla employees different from other members of the software community? Mozilla is paying its employees to be members of the community -- and to perform the tasks where they'd most effectively advance Mozilla's mission ( http://www.mozilla.org/about/manifesto.en.html ). There are other companies who pay people to work on Mozilla code (e.g., in the area of embedding, a number of Linux distributors have at various times). hence why i have requested - formally on mozilla.governance - for advice on how to go about making a formal request that the mozilla foundation a) adopt python-hulahop as a 1st level priority project b) reinstate pyxpcom as a 1st level priority project - preferably *back* into mozilla-central. c) introduce unit tests that, if not passed, will block the release of *any* xulrunner release at the time until such time as the bugs are fixed and the unit tests pass. Demanding that somebody else do work for you doesn't seem like an approach likely to succeed. the end result will actually be an *improvement* in the quality of the xulrunner and the firefox codebase because it will result in a different kind of testing - from a different angle with different code-paths of the exact same core components that are utilised in firefox. That's at least a more reasonable argument. I don't believe it, though. 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. You're not going to turn the latter into the former by shaking bugs out through additional testing. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
Hello, Would this terminate embedding gecko in WinEmbed at /mozilla-central/embedding/tests/winEmbed (I would like to use embedding technology in JAVA JNI Applet) Thanks for your answer, Joffrey ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
Your post brings up a few of the reasons why maintaining an embedding solution is not high on Mozilla's priority list. Embedders each have a different set of problems they are trying to solve and making a modular library stack might be the best way to serve those needs. However, making a modular library stack is exactly what Mozilla does not want to do, since this is exactly not the problem we are trying to solve. Mozilla wants to make products using the simplest, best methods. Methods that result in the best codesize and performance. One approach Benjamin and others have talked about is trying to find an embedding solution that very closely follows the approach Mozilla takes to building products. Firefox Mobile uses an out-of-process system for rendering web content. The main UI process spawns a separate child process and communicates with that process. User input (mouse and keyboard) are sent to the child process and the web content is rendered to shared image buffers which is then displayed in the parent. The child process doesn't even need a profile folder, one of the big gripes with the current embedding solutions. Would it be possible to create a generic, embedded system to allow a 3rd party application to spawn the child process and display the out- of-process web content? Probably. There are a lot of unknowns and we are still working the kinks out of the system. The biggest advantage to this kind of solution is that it's aligned with how Mozilla is shipping it's own products. Desktop Firefox is moving to the same out-of-process system. There would be a large overlap between Mozilla code and the embedding code. On Apr 6, 8:02 am, g...@novadsp.com g...@novadsp.com wrote: Some thoughts on this ... ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On Thursday, April 7, 2011 10:54:13 PM UTC, Benjamin Smedberg wrote: On 4/7/11 3:42 PM, sdenning wrote: 4) Even if we do not use gtkmozembed directly, are there other components that will be affected? Specifically, will there be an impact to programs like the wxEmbed test driver: mozilla/embedding/tests/wxEmbed/ I don't think that code is built, and will likely be removed also. It doesn't get built automatically, but it does serve as a good sample program and in a xulrunner-1.9.0.6 distribution I was able to build it. I guess my concern is whether the APIs a wx-based C++ embedded app would be affected with the removal of gtkmozembed. It seems like gtkmozembed was just the embedding of low-level gtk, where embedded applications that use wx (wrapper for gtk) would be unaffected? ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
Actually Eclipse uses XPCOM to embed xulrunner, and exposes JavaXPCOM to clients. So the second part is of course dependent on JavaXPCOM's fate, but the embedding part could continue on without JavaXPCOM. Grant Benjamin Smedberg benja...@smedbergs.us wrote in message news:mailman.1997.1302204651.16651.dev-embedd...@lists.mozilla.org... On 4/7/11 9:41 AM, CMB wrote: Would this terminate embedding gecko in IDE's (ex eclipse), TopStyle ecc.? Eclipse uses javaxpcom to do embedding. If somebody wishes to maintain that code, they may continue to do so, but it will not be built into XULRunner or available in the main mozilla codebase. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
Benjamin, 1) I'm unclear of the impacts of removing gtkmozembed. Can you please clarify which APIs and functionality will be impacted? For example, will XRE_InitEmbedding go away with these near-term changes? 2) I too rebuild mozilla for a special xulrunner application that plays nicely with legacy gtk+/wx applications to provide an embedded browser. However, I utilize a wrapper for my access - wxWebConnect which is supported by Kirix: http://www.kirix.com/labs/wxwebconnect.html Will the changes you identify here impact that project and the apis/utilities they use? 3) What is the timeframe for these changes? Thanks, Susan ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
Would this terminate embedding gecko in IDE's (ex eclipse), TopStyle ecc.? ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On 4/7/11 9:41 AM, CMB wrote: Would this terminate embedding gecko in IDE's (ex eclipse), TopStyle ecc.? Eclipse uses javaxpcom to do embedding. If somebody wishes to maintain that code, they may continue to do so, but it will not be built into XULRunner or available in the main mozilla codebase. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On 4/7/11 9:29 AM, sdenn...@rocketmail.com wrote: Benjamin, 1) I'm unclear of the impacts of removing gtkmozembed. Can you please clarify which APIs and functionality will be impacted? For example, will XRE_InitEmbedding go away with these near-term changes? gtkmozembed is the code in embedding/browser/gtk and primarily the functions in gtkmozembed.h. XRE_InitEmbedding is not affected. 2) I too rebuild mozilla for a special xulrunner application that plays nicely with legacy gtk+/wx applications to provide an embedded browser. However, I utilize a wrapper for my access - wxWebConnect which is supported by Kirix: http://www.kirix.com/labs/wxwebconnect.html Will the changes you identify here impact that project and the apis/utilities they use? I don't know, that depends on how they do their embedding. But of course, if they use gtkmozembed, they can import that code and continue to use and maintain it. 3) What is the timeframe for these changes? Immediately for Firefox 5. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
Thank you so much for the response! 4) Even if we do not use gtkmozembed directly, are there other components that will be affected? Specifically, will there be an impact to programs like the wxEmbed test driver: mozilla/embedding/tests/wxEmbed/ 5) Without javaxpcom, would there still be access to XPCOM objects via javascript? Thanks! Susan ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On 4/4/11 9:02 AM, Glen Gray wrote: I'll need to know what my options are going forward and how we will be able to control the browsers functionality (custom uri's trigger application launching, restricted access to uri's based on users credits etc.). Do I focus on using a swapping out GtkMozEmbed for a webkit browser or come up with something different. That is of course up to you. You could continue to maintain and use gtkmozembed yourself, or in combination with other people who want to try and maintain that code. You could switch to writing your kiosk as a XULRunner app, or you could attempt to switch to webkit (plus all the other libraries webkit requires, such as networking etc). What is the current status as regards xulrunner 2.0 ? This announcement has nothing to do with XULRunner 2.0. It does mean that the next following XULRunner will not contain gtkmozembed or the ActiveX control code. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On Wed, Apr 6, 2011 at 8:19 AM, Asa Dotzler a...@mozilla.com wrote: You seem to have missed the part where I pointed out Benjamen's call for those interested in helping make a simple multi-process embedding story happen. Then again, those who will do nothing more to make it happen than hope for it are probably wise to look to other solutions. I didn't miss it. But I imagine that most people who would hope for this are in a similar situation to me. I can invest a small amount of time, but not enough to get over the initial barrier needed to get started. It starts with the fact that the documentation appears to be ancient. What documentation there is is a bit off-putting - do I really need all of that stuff if my use-case is just to render some HTML+CSS to an off-screen buffer? The other avenues for getting involved in Mozilla offer baby-steps to getting involved. You can learn a lot of the front-end, for example, but starting out writing a plug-in. As near as I can tell, there are no baby steps to getting involved in Gecko embedding. Since I don't have the time to invest several months wading through the source code and trying to figure out which documentation still applies, I don't see any realistic way to contribute. I am willing to give a couple of hundred Euros to Mozilla to contribute towards a summer student, working with the support and mentorship of some Mozilla people, to improve the documentation. I bet others would too if you set up a donations page. Cheers, Ami. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
Some thoughts on this ... At least this gives those of us who were hoping for a nice embedding story for Gecko a chance for a clean break, so my commendations to the Mozilla team for providing clarity on the issue. 'embedding' covers a vast swathe of territory. It is relatively simple to embed Firefox in an application. It is nigh on impossible to embed (say) the SVG rendering system in an application, as it has dependencies on ... almost everything. Firefox was designed to be a standalone browser and not a collection of components that are easily plugged and played. As far as other browsers are concerned (Webkit/Chromium), they too suffer from gigantism and interdependency. Webkit is extremely difficult to 'embed' as the trunk relies on proprietary runtimes (CF/Quartz/Quicktime). There is an OpenCF/Curl/Cairo route but this is still (I believe) some way off oven-ready. The Chromium team have done an amazing job in integrating alternatives in Webkit but at an enormous cost. The current Chromium 'all' 'solution' (in Visual Studio terms) contains around 500 sub-projects. Little wonder the only people with the resources to do it are Google. There is actually a Chrome embedding project but this relies on patching a good number of sources and cannot be applied cleanly to any arbitrary release. Coming back to Firefox and the future, I believe that a good target would be a Firefox configuration that had no runtime dependencies on 'chrome' and configuration files etc, i.e. reduced to an absolutely minimal set of dynamically linked libraries. Hook all config/runtime stuff so the embedding host can supply it in a format and from a location that makes sense in the deployment environment. Extend and expose functionality to make it trivial to run headless. In an ideal world the minimal DLL set could be built and linked as a static library, which would be useful on smaller machines - think ucLinux and non-MMU processors. This implies having a build system that feeds off trunk but provides a greater degree of flexibility. I'd want to have the option to use static C/C++ runtimes as well. The acid test for success would be to be able to deploy a single binary that could display web resources, interactively or otherwise. Note that the above applies to my current use case, which is embedding in an existing Windows desktop app where HTML/SVG flexibility and interactivity are a major boost. However, an embedding project would probably want to support managed code too, be it C# or Python. I think we could dispense with activex/flash plugin support. All of this has to be done in a non-invasive way that takes full advantage of Mozilla's hard work in testing, and verifying both quality and adherence to standards. I think this beyond the resources of a SOC project. Personally, given the provision of an adequate wage, I'd love to have a crack at this. I'm open to offers :) Finally, my thanks too to the Firefox team. Amazing work and a great product. ATB Jerry. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
Yes I agree. And would also happily donate to the embedding maintenance. Could also help out myself, but have same concerns as described in the previous post. Actually I am investigating a crashbug which seems to have been introduced between FF4 beta 6 and FF4 beta 7. The crash happens within my embedded application ( wxWidgets ). I guess that will bring me some more insight to the code and to mercurial, since I guess I need to do bisection in Mercurial between the dates for those 2 releases trying to figure out where the crash happens. But I hear that XulRunner will still be supported, so perhaps I should just switch to that. I have very limited GUI implemented so far and as long as I can link in the PHP (Zend engine) runtime via plugin/ XulRunner something I might be fine. But still if you can find a student I would happily donate money. -Martin Lütken ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On Wed, Apr 6, 2011 at 12:31 AM, Asa Dotzler a...@mozilla.com wrote: No, that is not the question. There is no question about caring here and it's both rude an insulting to phrase it that way. I think it's a legitimate question. Maybe the thing is to phrase it differently: is embedding by third parties considered strategic enough to Mozilla's mission for it to invest its limited resources in it? I've wanted to use Gecko for embedding various times and ended up having to give up due to my own time constraints. There always ends up being some barrier to making it work that would take more time to solve than whatever project I'm working on will allow. I'd be interested in contributing back in principle, but first I have to become a user, and the barriers to that are currently very high. Especially given the existence of WebKit (which also has its problems, so it's not like there isn't a niche available for a really nice embedding solution). My opinion is that having a richer embedding ecosystem around Gecko would help bring in more contributors long-term and be a real boost to all the projects that rely on Gecko, Firefox included. But that would require more investment by Mozilla in make Gecko an attractive embedding solution to begin with. It's a catch-22 that can only be solved by somebody committing significant resources to the problem. More resources than an individual embedder can afford. I think Mozilla is the only party that can get the ball rolling. Cheers, Ami. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On 4/5/2011 8:22 PM, Ami Ganguli wrote: On Wed, Apr 6, 2011 at 12:31 AM, Asa Dotzlera...@mozilla.com wrote: No, that is not the question. There is no question about caring here and it's both rude an insulting to phrase it that way. I think it's a legitimate question. Maybe the thing is to phrase it differently: is embedding by third parties considered strategic enough to Mozilla's mission for it to invest its limited resources in it? Perhaps read the original post again? I'll try to tl;dr it. The person who leads the Mozilla project's embedding effort, Benjamin Smedberg, does not think that in-process embedding capabilities, including the current gtkmozembed, javaxpcom, and ActiveX work, are strategic enough to Mozilla's mission for *anyone* to invest resources there. The existing implementations are not only not strategic, they are incomplete, problematic, and their maintenance costs far outweigh any benefits so they are being removed from the Mozilla code repository. Benjamin then goes on to say that after separate-process rendering is implemented for Firefox we may consider ways to make really simple multi-process embedding a possibility. If you are interested in helping to begin implementation of this multiprocess embedding solution, please let me know, and I will help guide you in the right direction. So, if you care about a possible future multi-process embedding implementation, and you're willing to help or can find others who are, you may be able to get some help from Mozilla in making that a reality My opinion is that having a richer embedding ecosystem around Gecko would help bring in more contributors long-term and be a real boost to all the projects that rely on Gecko, Firefox included. But that would require more investment by Mozilla in make Gecko an attractive embedding solution to begin with. Speaking for myself only here, I've heard this from many people for many many years and I don't really believe it's the obvious win you and others think it would be. There's no free lunch and any efforts around building a better embedding solution and an embedding ecosystem have to come from other projects. I can think of several technical undertakings that, in my opinion, would do far more to help bring in contributors and make Gecko better than spending more efforts on embedding. - A ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On Wed, Apr 6, 2011 at 7:45 AM, Asa Dotzler a...@mozilla.com wrote: There's no free lunch and any efforts around building a better embedding solution and an embedding ecosystem have to come from other projects. I can think of several technical undertakings that, in my opinion, would do far more to help bring in contributors and make Gecko better than spending more efforts on embedding. Fair enough. I disagree, but I'm not in a position to do much about it. At least this gives those of us who were hoping for a nice embedding story for Gecko a chance for a clean break, so my commendations to the Mozilla team for providing clarity on the issue. Cheers, Ami. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
The question is: does mozilla care about stuff other than their products at this point? -- --Antonio Gomes ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
I would like to know that too. I don't use gtkmozembed or other stuff. I also don't need binary compatibility since I compile Mozilla myself. But does this mean that in the future I will not be able to embed Mozilla in my own application using the functions 'XRE_InitEmbedding2' and similar ? If not will there be other ways to achive the same? Apart from switching to Webkit that is. -Martin ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
