Google Groups

Re: The future of binary embedding


lkcl luke Feb 25, 2012 11:38 AM
Posted in group: mozilla.dev.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.l...@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.