John,
Interesting tone.
"What do you have against..."
"I don't think you can argue..."
We've known each other a very long time, but you'll have to excuse
me if I'm quite blunt in my replies. (Note to Open folk... I'm not being
a roll model here.)
John Plocher wrote:
> Joseph Kowalski wrote:
>> Perl decision, but I suspect you may find the reason we did this for
>> Perl was also an exception (one time event) and doesn't apply here.
>
> What do you have against allowing multiple versions of a given
> component to co-reside in the system? And why should we not reuse
> and/or update a multi-version model with which we have some
> experience?
I don't.
Everybody has been saying there is precedent. I *know* Java is not
the precedent and I suspect Perl isn't a precedent.
Without a precedent, we need all the policy rules written down. I'm
just asking for them. Without them, we don't have the foggest idea
what we are doing. This doesn't come close to the support Java has
for versions (Remember, command line arguments provide version selection,
its not just the path and they allow specification of a range of versions.
As a matter of fact, the paths themselves are Volatile. If I could have
made them Private, I would have.
You've seen my recollections about Perl. As I gently suggested to
Nicolas, we should all stop guessing the why's and wherefore's around
Perl and not assume this is a good model until we examine the discussion
which approved this layout for Perl.
Remember, I'm the guy who did the Java stuff. I didn't get it 100%
right. It is hard. I have the scars to prove it.
> I don't think you can argue that we don't need an architecture
> that supports multiple co-resident versions of a given component
> in our system, and that we should strive to use it for all instances
> of the multi-version problem that we come across.
I certainly can argue that (not that I am). I've been at Sun for 17 years
and for the first 14 of those years it was an absolute given that one
version,
forever upward compatible, was the LAW. It surprises me to hear you
say this, because I think you have been here for 11 or 12 of those 14
years I mention. Times change. Maybe the rule set should change.
However, I'm not about to do that lightly, because I strongly believe
this old rule set is why GM (Goldman Sacks, whoever) is a heavily
Solaris shop and not a FOSS/Linux shop. The "deal maker" to one
customer is the "deal breaker" to another. We must make a thoughtful
and well informed decision here.
What I'm asking for is a Policy and list of criteria to argue about (or
not).
Without that we are just a bunch of guys who like to hear ourselves talk.
(Apologies to W. Shakespear)
> I suppose you could argue that SAMPP's components are not ones that
> should use such an architecture, but I think that that horse is already
> out of the barn (apache1.3/2.0/2.2.4/..., php4, php5, mysql4, mysql5...)
Humm, I could have sworn I heard one of the leaders of the Apache project
took exception with this, on this very thread.
Note that I've also stated that I had little problem for the support of
multiple
versions based on Major and known to be incombatible versions (as by the
and mysql examples). What I am concerned about is supporting multiple
versions because we are either too lazy to test for compatibility or are
trying
to support applications which depend upon the implementation rather than
the specification.
> -John
I'l be back once I find time to read the perl case. I trust I am being
a roll
model in this regard.
- jek3
