🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sw.components
Article #305

What should a component library look like?

#305
From: Don Dwiggins
Date: Mon, 13 Nov 1989 20:54
43 lines
2869 bytes
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
Technical Details
Message-ID: <DWIGGINS.89Nov13125458@atsun.a-t.com>
Path: arc1-ca.pugleaf.net!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

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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: <DWIGGINS.89Nov13125458@atsun.a-t.com>
Date: 13 Nov 89 20:54:58 GMT
Sender: dwiggins@ashtate.UUCP
Distribution: comp
Organization: Ashton-Tate, Inc.
Lines: 43