Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!nsc!pyramid!athertn!paul
From: paul@athertn.Atherton.COM (Paul Sander)
Newsgroups: comp.sw.components
Subject: Re: What is a reusable software component? (long, includes code)
Keywords: software component definition
Message-ID: <27914@athertn.Atherton.COM>
Date: 27 Jul 90 21:05:03 GMT
References: <27705@athertn.Atherton.COM> <533@helios.prosys.se>
Reply-To: paul@Atherton.COM (Paul Sander)
Organization: Atherton Technology, Sunnyvale, CA
Lines: 61

In article <533@helios.prosys.se> ath@prosys.se (Anders Thulin) writes:
>In article <27705@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes:
>
>> [ ... deleted ... ]
>>- How can it be made better?
>
>By providing:
>
>* external storage capability
>
>  These should be some way to store the B-tree on secondary memory, so
>  that the data it contains could be reused in another program.

There are a number of features missing from this implementation that could
be useful.  These include Anders' secondary storage capability (which is
what B-trees are used most for), perhaps with multi user locking.  An
implementation that uses shared memory, again with multi-user
locking might be useful.  Still another that is implemented as a server
that could allow data to be shared across machines would be useful.

I guess these issues begin to illustrate why reusable software components
are so difficult to develop.  My implementation addresses none of these
issues, so its utility is limited to those applications that don't need
them.  On the other hand, applications that don't need the additional
features need not pay the overhead demanded by these other implementations
if my B-tree satisfies their needs.

This implies then, that a reusable software component includes in its
documentation a list of particular features and limitations, probably in
an index.  My implementation would include the following:
	B-tree:  in-memory, single user, single machine,
	         scope limited to single running applications

>* browser
>
>  That is, providing a `bt_user_search(tree)' which presents the data
>  in the tree, and lets the user select an item for further computation.
>
>This is something I think most components that implement data structures
>should have. At least those implementing `complicated' structures.

It is debatable whether or not a component should provide a browsing
capability or not.  It has no way of knowing what the client has stored
there.  It could, however, provide bt_getFirst, bt_getLast, bt_getNext,
and bt_getPrev functions that work in conjunction with the bt_search
function to provide the functionality needed for the client to locate
information and provide a more effective browser.

It is also debatable as to whether or not a data structure such as a
B-tree should provide the user interface code needed to support such a
browser.  On the other hand, a reusable Browser software component could
be designed that could work with a large number of data structures without
regard to their implementation.  It is easy for me to visualize a simple
user interface that provides commands for start, stop, move left, right,
up, down, in, out, and show summary or detail.  One such implementation
could register callbacks for each command and provide a way for the
client to format its data.
-- 
Paul Sander        (408) 734-9822  | "Passwords are like underwear," she said,
paul@Atherton.COM                  | "Both should be changed often."
{decwrl,pyramid,sun}!athertn!paul  | -- Bennett Falk in "Mom Meets Unix"