Re: Containers with Ada

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Stephen Leake wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
> > <snip>
> > > I would hope you would make an effort to contribute fixes and upgrade
> > > to later versions, but there's really no need to require your users to
> > > do that on their own!
> >
> > You don't specifically indicate what I should perform "fixes and upgrade
> > to later versions" for, but I'll assume that you mean my own contributed
> > applications.
>
> Sorry, I wasn't very clear. For example, if you distribute an app that
> works with Florist 1.1, but breaks with Florist 1.2, you should either
> upgrade your app to work with Florist 1.2, or fix Florist 1.2,
> whichever seems more appropriate.

The former is usually the simplest (which is what my normal response
is).  This leads to a quick solution to the user's email request.

The later case usually requires that you contact
the author of the offending package, and hope that he'll accept your patches.
Then, you must *wait* for it to be released. This process does not help
the poor user who has contacted you with a message saying
"your software won't compile". The emailing user often has no
appreciation for the fact that it _did_ compile with the
original components used.

Another alternative is to make patches to Florist 1.2 available to address
the issue, but this requires the poor user to apply, compile and install
them successfully. Many users are not up to this task.  Not only that,
it requires you to revisit this issue again when Florist 1.3 comes out
(assuming that your feedback to the Florist maintainers has not been
accepted, or taken to heart, or simply still "in the queue").

[NOTE: I am not picking on Florist here-- only using it as an example]

Even when cvs access to the package is available, and even if your changes
are adopted (they might be overruled), you then still must get the end user to
download those "improved sources" and recompile and install them himself.
This is fraut with more frustrated end users, and thus, more emails in my
inbox ;-)

Anyway, I am just re-stating my original statement here -- standards are
necessary to prevent most of this tussle.  If there is too much perceived
"hassle factor" to use an existing package, I won't use it. If it is small, or
if the components extractable from a larger package, then I'll include them
in with my sources, so that I can _insulate_ myself from those changes.

It would be nice to see more _STANDARDIZED_ packages available.
As I posted earlier, standards give the application writer confidence about
the future of the API and it's behaviour.

> > My goal for written applications, is to be the "May Tag repair man". I want to
> > be able to move onto _NEW_ projects, since time is a limited resource.  If I
> > must keep revisiting an application that does not need enhancing, just to
> > make it compile and work again, I get rather annoyed (when the change is
> > seemingly unnecessary).
> >
> > It's an imperfect world, so I accept the reality that changes are sometimes
> > required. But IMHO, it should be possible most of the time to build applications
> > without making a career out of it ;-)
>
> Yes, I totally agree. I'm working on Windex (a binding to Win32), and
> for now I feel free to change the user API, because I know it's pretty
> far from right. But at some point, it has to freeze, and just live
> with any imperfections.
>
> --
> -- Stephe

Certainly, anything that is truly "in development" has to have the caveat that
the API is subject to change. This is OK, since it allows others to take
advantage of the same work, while it is progressing. Others can contribute
(hopefully constructive) criticism, and patches.

All I am saying is that using existing packages in a state of "flux"
is often more aggrivation than it is worth, considering the long run.

Some people like to continue to enhance and build upon various open source
projects, and this is necessary for large projects.  I myself, have many interests,
including building solutions to new problems. As you agreed, we
don't like to revisit the same old stuff unnecessarily.

--
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg