Brendan Eich wrote:
>
> > This is quite an opportunity. It's a select few projects that see that
> > level of ubiquity. And yet mozilla.org seems indifferent, if not
> > altogether dismissive of this situation.
>
> Who @mozilla.org has been dismissive? Or indifferent, for that matter?
I'm not '@mozilla.org'. I'm not dismissive or indifferent. I'm
'anti'.
>
> I'm rattling cages by email, and drivers are following the API freeze
> work that valeski is leading (see mozilla.porkjockeys). mozilla1.0
> needs stability, performance, and frozen APIs to existing
> implementations -- not any particular new feature (as the roadmap says).
>
> I don't speak for netscape.com, but I'll say what all staff and drivers
> @mozilla.org know: being a system library on many distros is a victory
> condition, and it requires API freezes and a decent versioning story.
> We're working on the API freeze part, and still limping along on COM's
> versioning story. Suggestions?
I'm not a 'driver' and I'm not in on mozilla.org decision making.
I *do* know that it would help if you got your story straight on
exactly what mozilla.org thinks the codebase is for. From
<http://mozilla.org/mozorg.html>:
"Our Mission
We coordinate the open source Mozilla browser project. Mozilla is
an open-source web browser, designed for standards-compliance,
performance and portability."
Following the link there to <http://mozilla.org/mission.html> we
find that the *revised* mission statement is pretty light on the
use of the term 'browser' (and has unbalanced parens):
"So, Mozilla is a set of technologies, but not a specific (in
biologic terms, Mozilla is a genus; a particular product is a
species. And mozilla.org (pronounced Mozilla Dot Org or The
Mozilla Organization) is the group of people who coordinate the
project."
FWIW, my opinion is that mozilla should focus on producing a
browser and only contemplate going beyond that when those with
other plans for the code can show that their plans are coherent,
not in conflict with the browser goals and will not unduly burden
those working toward browser goals.
As far as this system library stuff goes, I think you're letting
people blow smoke up your ass :) ...
My understanding is that valeski's work is not generally about
freezing any APIs, but more about determining what APIs to
support for *browser* embeddings and setting up a process for
limiting change and negotiating said change, as needed, with his
group's customers.
Using xpcom as a system library is not limited simply by API
deltas and versioning, but also by the fact that some core xpcom
systems (and plenty of other systems in mozilla) do not support
being used by more than one process at a time! We maintain
critical state in files which we read and write. We don't have a
system for synchronizing access to those files. Nor do we have
any systems for notifying between processes when those files
change.
We don't have any abstraction for "state of xpcom for this
application using the DLLs". I don't think we want a "per user"
config state for things like installed components etc. We do have
a 'per installation' abstraction. But it is not setup to support
sharing and it is limited by doing its mapping of installation to
config files by simply storing the config files in the same
directory as the DLLs. No one has even bothered to provide a
mapping where the config files can go elsewhere yet still retain
the "these DLLs with those config files" relationship.
There seem to be people surfacing who are devising product
strategies based on leveraging the libraries installed by one or
another vendor. This is a dangerous course. As you've noted. you
can't speak for Netscape (nor can I). Neither of us can speak for
any other vendor of binaries that are based on mozilla code. But,
the code we have in the tree can do nasty things if different
processes try to use it at the same time.
I'd argue that any freezing of xpcom code is based more on a lack
of ownership or coherent plan and schedule for xpcom's evolution
and not any 'doneness' of the system.
Again, I think that people wanting *someone* to make mozilla DLLs
into system libraries are dreaming. There is significant work
necessary to make that happen. That work is not on anyone's
schedule (AFAIK) and it impacts those trying to deliver browsers
- the support of which, I think, *should* be the unambiguous
stated goal of mozilla.org. I don't think that assuming that this
work will be done is wise. And it is much less wise to assume
that it is safe to leverage the mozilla based DLLs installed on a
given system.
John.
>
> /be
