Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!swrinde!cs.utexas.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!hacgate!ashtate!atsun!dwiggins From: dwiggins@atsun.a-t.com (Don Dwiggins) Newsgroups: comp.sw.components Subject: What should a component library look like? Message-ID: Date: 13 Nov 89 20:54:58 GMT Sender: dwiggins@ashtate.UUCP Distribution: comp Organization: Ashton-Tate, Inc. Lines: 43 I'd like to raise an issue in another direction from most of the topics I've seen here, but well within the topic of SW components. Given a large number of potential components within an organization, how are they to be organized, made available, kept current, validated, etc.? Roughly, what is the role and task of the "software component librarian"? Here are some questions in this area; you may wish to respond to some of the unstated assumptions as well as the questions themselves. Opinions are welcome, of course, but experience would be even more valuable. How much effort and resource expenditure is worth putting into building and maintaining this library? Is something like the comp.sources.xx archives adequate, with minimal maintenance, reliance on authors for description and quality, and a sort of caveat emptor approach to distribution? In the following questions, I'll assume that a more active approach is called for. What measures of quality should be expected of a component, e.g. freedom from bugs, portability, generality, optimality in some dimension? How are these to be assured? Who's responsible for this: the original authors, the librarian, the user community? It seems to me that separation of functional specification from implementation is at least a Good Thing, if not absolutely necessary for a viable library. This would allow a variety of implementations that meet the spec, and that vary in their performance details (memory, speed, language, operating system, etc.). In addition, there should be a hierarchy of generality of the specs, so that a user can pick the most specific (and thus presumably the most efficient) specification that suits his needs. Is this overkill? Are there problems or pitfalls here? How are improvements/upgrades/fixes to the components to be managed? Do we try to keep track of the folks who've "checked out" components and notify them of the new stuff? Should there be a way to "obsolete" components? Generally, what does configuration management look like in this environment? A final note: these questions are set in the context of a single organization, assuming a cooperative, open community. A similar discussion would revolve around various commercial settings. -- Don Dwiggins "Solvitur Ambulando" Ashton-Tate, Inc. dwiggins@ashtate.a-t.com dwiggins@ashtate.uucp