Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!ncrlnk!ncrcae!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.sw.components
Subject: Re: What should a component library look like?
Message-ID: <7049@hubcap.clemson.edu>
Date: 15 Nov 89 01:10:15 GMT
References: <DWIGGINS.89Nov13125458@atsun.a-t.com>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Distribution: comp
Lines: 59

From dwiggins@atsun.a-t.com (Don Dwiggins):
> what is the role and task of the "software component librarian"?  

   To manage an interface between component producers and component users.
  
> 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?  

   Components should be categorized as to quality; the task of doing
   this is simplified considerably by the existence of a software
   components marketplace.  Unfortunately, the currently large number
   of programming languages in production use fragments the market,
   and has been a major inhibitor.  Another problem is the existence
   of languages which are not standardized and for which no compiler
   validation capability exists.
 
> 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?

   All of these should be expected of a professionally written component.
   Assurances can be obtained in the form of product reviews, explicit
   guarantees from the manufacturer, etc.; where such quality information
   is not available (e.g., when the component is locally produced), the
   librarian should give the component an appropriate classification.  If
   there is sufficient user demand for a component of higher quality, the
   librarian should consider whether the demand will justify the expenditure
   of the testing resources needed to achieve a higher classification.
 
> 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?

   It's not overkill; this is one of the big advantages of using a good 
   component catalog.  Major problem, IMHO, is the fact that a good-sized
   market is required to sustain this kind of a selection, and the above-
   mentioned market fragmentation makes this very difficult to achieve.
 
> 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?

   If the components are local, and written in Ada, then Ada already 
   provides configuration management.  Otherwise, some sort of tool 
   is needed for local configuration management.  If the components
   are non-local, then arrangements will probably have to be made 
   with the component's manufacturer or distributor.
 

   Bill Wolfe, wtwolfe@hubcap.clemson.edu