[liberally edited...]
On Tue, Jan 16, 2001 at 11:32:09AM -0800, John Bandhauer wrote:
> Brendan Eich wrote:
> >
> > 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.
>
> 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):
>
> 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.
I'll tell you this: mozilla is *damn close* to being the ubiquitous system
web-content component on a *very* wide variety of systems (to the point that
we *will* drop IE even on windows when we see mozilla get where we need it
to be).
>
> As far as this system library stuff goes, I think you're letting
> people blow smoke up your ass :) ...
I hope not :) there are a hell of a lot of people looking very forward to
making mozilla a central part of a lot of very interesting projects. if
mozilla refuses to play that role, a huge amount of development effort would
have to be spent taking GtkHTML or Konquerer and bringing it to where
mozilla is.
And i *don't* think that level of flexibility is unacheivable by 1.0 (i.e.
in the next few months).
>
> 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.
>
> 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 have a secret for you: *all* of mozilla *always* runs on *every* unix
*without* write-access to those system files (with the exception of at
install time, and if root ever starts it up...). That argues to me that
fundamentally things are fairly close to being where they need to be;
already any mozilla-embedding application is fine sharing the system copies
of mozilla libs, as long as it doesn't need to
- register new components
- register new types (i.e. provide new typelibs)
am i missing anything?
>
> 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.
>
But i think the two above lacks *can* be fixed with some concerted effort.
And i think the people are out there for whom this functionality *is* key
and who *will* put it on their schedules. Just because there's no one
officially within the mozilla project now doesn't mean things should stay
that way.
I totally agree, a freeze in XPCOM now would be a terrible idea. but we've
got plenty of time before 1.0 to get the stuff we need done, and i certainly
hope no one is seriously breathing down our neck expecting a freeze this
very instant ...
ari
