Shared libraries are not necessary

[Jay Logue]

In article <211 at titccy.cc.titech.ac.jp> mohta at necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>In article <1991May17.075555.29787 at Think.COM> barmar at think.com writes:
>
>>There are two kinds of software upgrades: those which change the interface
>>to the library, and those which only change the implementation.
>
>>Most of the common shared library designs only make the second kind simple.
>>That's certainly better than nothing.
>
>And, my claim is that the second kind is almost nothing.
>
>Your (those who support shared libraries) example of DNS prove that.
>
>Most software upgrade is a little more complex than can be processed by
>mere library change.
>
>						Masataka Ohta

I have been following this (lively?) thread for a while, but given the
statements above, perhaps I've missed something along the way. 

You seem to be saying that the ability to upgrade a program or set of
programs without recompilation by replacing a common shared library is
of no value, and does not in itself or coupled with any other ability
justify the use of shared libraries.  You cite the previous discussion
about DNS as a proof of this assertion. 

However, this proof provides the DNS example as its only argument,
whereas your assertion of the value of shared libraries applies to all
possible shared library uses.  Are you also stating that the DNS
example is universal for all uses of shared libraries for the purposes
of software maintainance/configuration?  That it is the only possible
scenario for the use of shared libraries?  Do you mean to say that
someone could not (and has not) come up with a use of shared libraries
that is in some way valuable to themselves and their customers?

If this is the case, I challange you to prove it.   If this is not the
case, then I can see nothing that supports your conclusion.

As for myself, I believe that your argument is far too narrow to
invalidate the value of shared libraries.   Furthermore, I believe that
the use of shared libraries for the purposes we are discussing is very
valuable and will become even more so in the future.

It is very easy to imagine two applications developed by seperate
companies that co-operate using a shared library interface module that
is coded and _maintained_ by a third company.  The maintainance
relationship would exist between the end-user and the third company
directly and, indeed, the two applications development compaines need
not even be aware that their applications co-operation let alone aware
of the fact that the code with which they co-operate is the subject of
periodic updates.  I believe this sort of relationship exists right
now within the OS/2 environment (with Microsoft being the third
company).

As a final note, I would ask you to be a little less confrontational
in your reply than you have been in previous replies.  In posting this
message, my intention is to promote a discussion which has, at least
up to this point, been very educational for me.  I am not interested
in receiving a reply littered with rude remarks or personal attacks.



Jay Logue

===============================================================================
INGREDIENTS: Jay Logue's personal opinions, cute signature,
physical/electronic addresses, and one or more of the following used
as a filler: assorted quotations, extraneous punctuation, white-space.

CONTAINS NO OFFICIAL EMPLOYER OPINIONS OR POSITIONS.

Not to be taken internally.  If accidentally injested, flush with
generous quantities of Jose Quervo Gold and consult your nearest
bartender immediately.
===============================================================================
Retix

USMail: 2644 30th Street, Santa Monica, CA 90405-3009 U.S.A
   Tel:	(213) 399-1611
   Fax:	(213) 458-2685
 Telex: 4944307
E-mail:	jay at retix.com
 X.400:	C=US;ADMD=TELEMAIL;PRMD=RETIX;O=OSI ONE;S=LOGUE;G=JAY
===============================================================================