John Plocher wrote:
> Stefan Teleman wrote:
>> Garrett D'Amore wrote:
>>> So, if standards compliance is key, then lets have a *full* case
>>> detailing the following:
>
>> These requirements are completely beyond the scope and intent of this
>> ARC Case.
>
> I tend to agree with Stefan here - what is wrong with a case that
> simply adds a new component without resetting the expectations
> surrounding the current one? In other words, how is this case
> architecturally different from our other recent cases that added
> commands that were similar-but-not-replacements-for existing ones?
Middleware and confusing link compatibilities. This isn't just like
adding another grep implementation or a different "make". Its adding a
middle layer that is *fundamentally* incompatible with our "approved"
middleware.
What do we tell consumers? Which library should they use? The library
this case proposes will require extra contortions to use, and will not
be used by another Sun supplied middleware, so if you use it, you can't
mix it with any other code not explicitly recompiled with it.
Conversely, apparently what we ship is not standards compliant.
This is a lose-lose situation.
We need to turn it around into a win-win situation. The best way to do
that is to get to a situation where we universally bless (and fully
support, including making it the default choice and making sure that all
of our middleware supports it) a standards compliant library.
>
> Adding a new command or library to the repo is a separable act from
> deciding to promote one of them as a preferred version.
This is a lot different IMO. We're talking about introducing
fundamentally incompatible building blocks into the system, and not
giving any guidance to users or developers as to which they should use.
Or even a way for developers to know if they are going to use a
middleware component which C++ library they are going to need to link
against.
Please go back and review the madness that happened in the Linux world
when there were two GNU libc's in common use. It was *not* a good
thing. This case proposes going down the same road, but without even
having a plan to ultimately obsolesce one of the implementations. (At
least the Linux libc problem resolved itself after time since there was
a clear succession.) Its an open-ended situation of madness without any
guidance for developers or even end users. (Recall not everyone that
compiles code is a developer.) That's architecturally wrong for
everyone, I think.
>
> If the compiler team wishes to follow your suggestions in a new case
> that attempts to standardize on a newer C++ STL, that would be OK
> with me; however, forcing *this* case to do more than articulate what
> Stefan has already said about mixing and matching seems a bit much.
Again, this is *not* like any other component. Its a fundamental
building block, and ultimately, if we're going to ship it, its going to
become a huge call generator when folks try to use it but find out that
there are incompatibilities with different middleware layers.
I also think there needs to be some work done (perhaps in the linker
group) if this is going to be an ongoing concern, so that there is a
link-time failure (with suitable messaging) when incompatible C++ run
times are loaded into the same address space. *That* might be beyond
the scope of this case.
I think the submitter is trying to slide something "under the radar",
and ignore the major issues that this is going to create. I'm extremely
dissatisfied with any "not this case" kind of response to these issues.
I'll note that I've also received mail from at least one major partner
who uses Studio C++ and STLport that more choice is *not* the right
answer -- a more comprehensive answer is required, and that yes, a fully
supported/blessed transition to a fully standards conforming library is
greatly desired.
Now, by way of a compromise, I *might* be satisfied with an addendum to
this case that forbade shipping any middleware (read libraries) -- or at
least middleware with stability beyond Project Private -- built with
this C++ library until a formal case addressing my concerns was brought
forward. However, I suspect that this would seriously degrade the value
that this project had hoped to bring to the table, since the limitations
would probably prevent a huge majority of the likely candidate users.
(It also flies in the face of the proposed Committed stability.)
Unless something changes here, I feel so strongly about this issue that
I'm likely to come out of sabbatical just to derail this case, if nobody
else does first. I'm *not* trying to prevent us shipping Apache's
product -- I suspect that the best situation for all involved is if we
can get libstdc++ (or possibly STLport5 -- I'm not prepared to judge
between them) adopted as a replacement "default" library, and obsolesce
the older stuff. But we need to evaluate the project fully.
By the way, the project has also failed to describe how the l10n data is
managed/accessed. This is a significant deficiency in the project's
specification. Projects using this touted i18n features of this library
need to know what the implications are for them... how do they deliver
localized data, etc. This is the sort of information that I expect
would be exposed in a full case.
I also haven't heard the compiler folks chime in. Adopting this case
without getting their input would, IMO, be grossly irresponsible.
-- Garrett
