In article <20010131222606.B243@andrew>, "Ari Heitner"
<[EMAIL PROTECTED]> wrote:
> I've had good luck with multiple GL installations. It takes some human
> mucking to move files around appropriately depending what you want to
> do.
When I find I must manually juggle libraries just to get an app running,
I don't generally consider myself "lucky". The skill required to do this
is beyond most users. Installation should be able to be *completely*
handled by an automated installation procedure.
> And the packaging/installation story needs to be well in place. Mozilla
> is actually in fantastic shape as far as that goes -- it depends only on
> very standard stuff, and keeps all its own stuff nice and out of the way
> (and harm's way).
The low dependency count is certainly a good thing; the fact that
xpinstall is oblivious to the presence of package managers is not. The
fact that core dependencies haven't been effectively factored out into
subcomponent packages *that other code can easily depend on* is another
problem, and central to the accessibilty issue I've been harping on.
>> Brendan says that Mozilla is "limping along" on COM's versioning
>> system. But from what I can see, Mozilla is barely using COM's
>> versioning system. As with the GL library problem (which is subsiding
>> on Linux at least, now that Mesa is bundled with XFree86), I think this
>> is more a problem with the implementation of the theory rather than any
>> fundamental flaw in the theory itself.
>
> Again, I don't see the evolutionary-interfaces theory of the COM gurus
> being used successfully *anywhere*.
Perhaps ironically, that's much of the rationale behind my "freeze early,
freeze often" suggestion...
> I think the interfaces change too often and too subtely to make "new
> functionality requires a new version of the interface, which supports
> the old version" a reality for the internal version story
This is what I was talking about when I said that people too often don't
properly discriminate between a new version in the same product line and
a new product line. If maintaining the old interface as a subset of the
new interface is impossible or impractical, I think it's time for a
completely new interface (that is, a new product). If you have to
duplicate functionality present in the old interface, that's a bit of a
PITA, but hardly the end of the world.
>(i.e. what
> happens between mozilla developers as mozilla advances from one release
> to another). Supporting old interfaces while creating a new interface
> *every* time you change something is just *way* too much of a burden on
> developers.
>
> Clearly developers need to be free to have stuff swim around loosely
> between releases, and only lock things down when say minor releases come
> out (i.e.
> 1.0, 1.1, 1.2). That's quite reasonable -- anyone crazy enough to
> develop
> against nightly CVS has got to be ... pretty crazy :)
Here is the problem: mozilla.org isn't making sufficiently frequent
"locked down" releases that other developers can both reliably develop
applications against, *and* then distribute those apps without fear of
them breaking in the future in very unpredictable and unfortunate ways.
Do not mistake that statement for a pointless plea of "1.0 yesterday!"
(The plea may be just as pointless, but it has a different aim.) "1.0" is
for the most part an identifier that says, "with this version, we think
we accomplished what we initially set out to do". A stable release with
frozen interfaces need not meet that standard. There is a persistent
notion that Mozilla doesn't need to be stable until 1.0. That has been
crippling since it is generally agreed that 1.0 should be postponed until
the browser meets the initial goals of full HTML4 and CSS1 support (among
other things). But 1.0 is ultimately *just another milestone*. There
remain others to come before it, and more will come after it. Why should
1.0 be the only milestone at which interfaces get frozen? Surely no one
is fooling themselves into thinking that no interfaces will need to
be changed after 1.0.
> But then the question arises: why bother supporting all the old
> interfaces along with the new ones? Since *every* damn object in there
> is slowly being phased out with respect to its newer implementations,
> you have a continual flux, and you never know when you can finally kill
> an old interface that's hanging around.
This is why I think a deprecation mechanism is necessary. Interfaces
marked deprecated could trigger a warning in the XPIDL compiler. After
some period, they could then go away.
> Maintaining all that old stuff remains too much of a headache.
Since the old interface isn't going to change, maintaining it should be
pretty trivial *as long as you aren't contaminating the old
implementation with your new one.*
> a) Move all the versions at the same time, i.e. at minor version changes
> b) support multiple installations (mozilla does this fine already).
>
> now you can kill old interfaces without worrying -- anyone who needs
> backwards compatibility can just install an old version. the caveat is
> that you have to support the old version as far as critical
> bugfixes/security updates goes. so you have to fork the CVS tree.
>
> But why is that unreasonable? every other major project (the kernel,
> GNOME, KDE, gimp, you name it) has both a stable tree and an unstable
> tree.
Agreed, especially that Mozilla needs a stable tree in a bad way.
> but now that you've got a consistent version number story for doing API
> changes (i.e. the API will remain constant across revisions of a minor
> version, and will change between minor versions), you can just change
> the interfaces without supporting old ones or renaming them :) and now
> we're
> *exactly* where the rest of the (sane) world is.
It's just crazy enough to work, I think. Coupled with a deprecation tag
in XPIDL to warn developers, major version changes could be used to
schedule purges of deprecated interfaces.
> What did the COM gurus think they were fixing, exactly?
"History" is my guess. But history will inevitably be revised to meet the
anticipated needs of the future. It's that damn "present" part that keeps
screwing us. :-)
Braden
