John Plocher writes: > Darren Reed wrote: > > For people outside ON, I'd contend that Consolidation Private is the > > same as Project Private. > > And all that means is "warning - implementation detail ahead, not > intended to be used as an interface into this functionality!"
True. I think a bigger point to be made here is that the assertion that "Consolidation Private" is the same as "Project Private" anywhere outside of ON is false. The issue is the existence of a consolidation. If you have some place where you build all of the bits of two or more projects together and deliver the resulting binaries, then you have a consolidation, and it's possible to manage private interfaces of that type. If you build each project independently, manage the source separately, and deliver the binaries from each, then you don't have consolidations, so "Consolidation Private" just makes no sense. Nobody's forcing anyone to have consolidations, but if you do, then "Consolidation Private" is one of the useful tools you have available to document and manage dependencies. > Bottom line for me: If it *is* an implementation detail, *Private > is the right answer. If it is a new intended-to-be-public experiment, > then it shouldn't remain *Private very long, because (other than > being an oxymoron) private public things always seem to cause us > problems. I agree. But as with the long-suffering folks dependent on the file system interfaces -- who've been in this boat *far* longer and with much worse results than anyone looking at GLDv3 could imagine -- it's much easier to say that than it is to *do* it. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
