Garrett D'Amore wrote: > What do we tell consumers? Which library should they use?
Exactly what we tell them today. "Use the stuff shipped with Studio". The customers will do exactly what *they* do today: Download and use the Apache Standard C++ Library. Except that they won't have to download it first. > Conversely, apparently what we ship is not standards compliant. Not this case. Gee, it would be nice if..., but it isn't. > This is a lose-lose situation. Good advice to the Sun Tools team, but again, not really this case. > 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. Also good advice, but it doesn't preclude offering our customers the very same choices they already have today: you can use our stuff now, you can hope we improve our stuff in the future, and/or you can use this other stuff. Gone are the days where it is normative to force ourselves or our users into a one-size-fits-all wardrobe. Yes, it is good to be able to deliver an integrated system; no, it isn't a showstopper for everyone else if we don't. > Please go back and review the madness that happened I don't disagree that madness lies down this path. Rather, I'm arguing that the using the threat of potential future madness to stop others from delivering components until *Sun* commits to doing something is a syntax error in an open source community. > Again, this is *not* like any other component. Its a fundamental > building block, How is it different from trying to mix Motif, GTK+ and KDE libraries in a single X application? Or trying to use g++ libs in a Studio application? In all these cases, we explicitly tell the user what the constraints are, and what they should expect to work and what shouldn't. Same here. Stefan needs to ensure that the docs tell the user all about these issues so that they don't try to crosslink things. He needs to say "here be dragons". He does not need to boil the ocean. > I think the submitter is trying to slide something "under the radar", You are reading too much into this. No conspiracy here, just a desire to provide a library that are customers are *already* downloading and using. Pandora's box is already open; this case doesn't make things worse. > 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'm really disappointed that the compiler team hasn't jumped in to this discussion. Have they been contacted and invited? > 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 Forbade *who* from doing so? Sun? OpenSolaris? Nexenta? Schillix? Slippery slope? > By the way, [other good points...] > I also haven't heard the compiler folks chime in. Adopting this case > without getting their input would, IMO, be grossly irresponsible. I can agree with this :-) -John
