In article <[EMAIL PROTECTED]>, "Robert O'Callahan"
<[EMAIL PROTECTED]> wrote:
> "Robert P. Krajewski" wrote:
>> Perhaps people need to stop looking to Netscape as the place to get a
>> browser that integrates with their OS of choice. Instead, separate
>> Gecko-hosting applications will need to be written instead.
>
> You're quite right. They are being written --- Nautilus and Galeon, for
> example.
Unfortunately, thanks to the monolithic development model imposed by
Netscape, getting and using Just A Component of Mozilla is unduly
difficult. It ought to be as simple as
$ cvs co gecko
$ cd gecko
$ ./bootstrap
$ ./configure
$ make
It's not--by a long shot.
Look at Nautilus. The preview releases depend on a friggin' *Mozilla
RPM*. Hello? A *single* RPM for *all* of the components that make up
Mozilla? Why? This was supposed to be *component software*.
You can fire back that a "gecko" or a "mail-news" RPM can still
(theoretically?) be produced. I imagine it could, but given the fact
that such a useful and obvious thing *hasn't* been produced, I am left
to assume that the Mozilla build architecture makes the creation and/or
maintenance of such RPMs unduly difficult.
Somewhere along the way, mozilla.org allowed a critical benefit of
component software to be steamrolled by the development culture of
monolithic applications. The cost has been the accessibility of the
Mozilla components to other developers. This has cost mozilla.org
contributors by narrowing the pool of available developers down to
either those who want to devote their time to helping develop the
Mozilla or Netscape browser, or those who can afford to leap the
hurdles to accessibility blocking the component libraries. And it's not
just a matter of developer competence. For many Linux developers,
depending on a particular library just isn't an option if the library
can't be easily downloaded and installed by moderately capable users.
Braden
