3rd-party app dependencies

Jan Bottorff janb at pmatrix.com
Mon Jan 11 05:12:31 UTC 1999


At 05:14 PM 1/10/99 -0500, Brian Sutton <bsutton at vt.edu> wrote:
>I'm a Squeak newbie.  One question I have is how to make one person's
>code run on another person's image after the end-user has changed
>who-knows-what in his system.  You don't have a consistent API provided
>by hardware/OS/Java/etc.  Some changes, e.g. UI behaviour, should be
>preserved, while others might cripple the new code.

Depending on how you look at it, this either has allways been a problem
area for many Smalltalk's or else the situation is exactly the same as
typical non-dynamic languages, such as C++.

1) If the expectation is you will be able to load software components into
YOUR customized image/VM of some version, then you will need to let go of
those expectations. To me, this is a very slippery slope, more on that in a
second.

2) If the expectation is you will be able to distribute closed binary
applications, then Squeak or most other Smalltalk's are no different that
say C++. You make a closed binary image/VM pair and distribute this. Users
can't change anything, but they also don't have to worry about version
compatability issues with the image/VM. Having a way to bind the bits
together for a matching image/VM pair would be helpful (like allways
default to an image with the same base name as the VM if no image is
specified (or mabey look in some sort of configuration file with the same
base name as the VM).

I believe the religous question goes: is it desirable to allow end users to
replace software components that may be part of some applications. To give
a non-Squeak example, when you install the Microsoft Windows NT 4.0 OS,
part of the standard system code knows how to play certain formats of
multimedia files. You can also install updated multimedia playback
components that expand the range of this multimedia playback. The key issue
is, this expanded support will automagically become part of "closed"
applications, provided they originally used certain system API's to access
multimedia playback. As a matter of fact you will be FORCED to get these
updated multimedia playback components when you install certain
applications, for example Microsoft Internet Explorer 4.0. I personally had
a issues pop up in a stable piece of software I sell, all because Microsoft
changed some component.

Bear with me for a moment, and let's examine the implications of
dynamically letting users update components.

The theory goes, since the software interface is supposed to be well
defined you can change components to any implementation desired, without
breaking anything. So who here believes they can write a new class that has
an utterly different implementation, and they can plug that class into
everybody elses code, and never break it? My belief is that keeping the
implementation separate from the interface helps code reusablity a lot. I
don't believe it's possible to have this perfect component utopia of
utterly interchangeable components. I personally have a hard time honestly
telling my customers that software I write will allways correctly function
if they change some component to be anything different that the exact
component I tested with. I also believe the overall stability of our
systems is degrading because of this random shuffling of components. This
is EXACTLY what's happening to Microsoft Windows based systems. It would be
my preference that Open Source systems do not make the same mistake.

I'd also like to suggest that delivering field replaceable component based
software allows programmers to get really sloppy. They can deliver a piece
of junk, and it's then easy to spend the next year sending out incremental
updates that fix some bugs and cause other new ones. An equilibrium of
minimum bugs may never be reached if components are shared between
applications. Late last year, I had this exact problem, either I could
install the component updates that made my personal accounting software
work (MS Money) OR I could install the component updates that would allow
my business accounting software to work (Intuit QuickBooks Pro). I didn't
feel dedicating a machine to each was exactly a good solution, so I spent
about 6 hours of serious programmer debugging to figure out what to do. The
final conclusion: it's impossible to allways a solution, although in my
case I was lucky and found a solution to "appears" to work. I'd don't
really have any idea if my accounting software actually is working
correctly, as I have no test suite to verify every little corner.

It used be be, you could deliver an application and it would keep working
exactly the same for 10 years. It's functioning didn't become more or less
correct over time. I still have old MS-DOS programs that still work exactly
correctly, 15 years later.

I can also argue the side of everything should be replaceable components.
For example, imagine EVERY applications written in the last 25 years used
the same replacable component for doing time/date/leap year calculations.
Much of the problems of Y2K could be fixed by updating a single software
component. This sounds EXTREEMLY attractive as the saving in work would be
astronomical.

Let's also consider the scenerio when programmers use a large shared base
of components, but when they deliver an application, the component versions
are fixed and generally can't be changed by end users. So now the
programming effort to integrate new components is still pretty low,
although testing still needs to be done for distributing a final
applications. End users don't find applications that used to work, stop
functioning correctly because they updated some unrelated application that
happened to update a shared component. My current belief is this last
solution is the best. Let programmers share a large base of components, but
snapshot things when you distribute the application. It so happens, this is
exactly the model used by Squeak.

So what do others think about the tradoffs of dynamic component updating
(with potential version skew nightmares) vs. a closed "static" universe we
call an application. I could image there might be some sort of shared
component version control that could provide the best of both worlds.

- Jan

___________________________________________________________________
            Paradigm Matrix Inc., San Ramon California
   "video products and development services for Win32 platforms"
Internet: Jan Bottorff janb at pmatrix.com
          WWW          http://www.pmatrix.com
Phone: voice  (925) 803-9318
       fax    (925) 803-9397
PGP: public key  <http://www-swiss.ai.mit.edu/~bal/pks-toplev.html>
     fingerprint  52 CB FF 60 91 25 F9 44  6F 87 23 C9 AB 5D 05 F6
___________________________________________________________________





More information about the Squeak-dev mailing list