No GnuPG library for now

[tftp]

--- Frank Tobin <ftobin at uiuc.edu> wrote:

> This is starting to get off-track, but there are two major trains of
> thought on the whole issue; we have the 'design' process (a.k.a. Rational
> Unified Process, a.k.a. RUP) vs a 'evolutionary' process (a.k.a. Extreme
> Programa, a.k.a. XP).  There are heavy debates on both sides of the issue
> which is better in the long run, which is better for which things, etc.

Some software is developed from "Requirements" document. This is the
foundation of RUP. From there you construct your methods, data flow,
algorithms, code and tests. After the software passes its own tests
it is done. No further development is possible with this software, only
occasional maintenance (bug fixes) because the design does not allow
"unnecessary" extensions and additions that were not planned beforehand.

For example, you can not easily add a plow or lawnmower to your car
(unless you watch "Red Green Show", of course :) This is because the
car was designed as final, complete product. At most you can add a
cup holder or better radio. This is RUP design.

Another example would involve a farm vehicle. It was -designed- to
work with various accessories, existing and future, as long as they
conform to some predefined and cast in stone interface. This is less
rigid design, but nevertheless it is not an evolutionary approach.

To see a vehicle that uses evolutionary design we can go to F-1 or
Indy race track. Very little is fixed there (and what is fixed is
so mostly because of rules of the sport). Every year you see changes
here and there - different wings, better engines, smarter computers.
This I would call an evolutionary design. It starts not with a good
description of the final product but with a good understanding of
what that product must do. The weight shifts from implementation to
fitness to the purpose.

With regard to GnuPG, is it fair to say that the program must do this
and that and nothing else? Do we -have- a formal specification of what
the final product will be? Most importantly, do we -need- such
specification? Parts of the code that interface with other components
(like 3rd party shells) would benefit from such standard. However the
rest of the code, I think, could be better treated as a "black box".
As long as I can invoke gpg in some predefined ways I, as user, don't
care if gpg uses callbacks to get to ciphers or it has a huge switch()
statement hardcoded somewhere.

That's why I was unhappy about yet another option being proposed for
GnuPG. The command interface must be designed as RUP because it
is an external interface and too many other programs depend on it.
However the internal structure of modules should be hidden from
any other code that does not need to know. Interface/Implementation
concept is pretty old - I believe Modula 2 had it long ago.

Anyway, the point is that RUP is a well known reason of -failure- of
large software projects when applied incorrectly. Try to order a
custom suit without trying it on couple of times before it is done.
If a tailor can't make just a suit then how much harder would it be
to foresee all possible changes that implementation may require!
RUP design is much more rigid than a XP one; the result is weird
extra variables passed back and forth, kludgy callbacks where there
shouldn't be any, etc. etc. - only because the "right" change would
involve several components, not just one. Often the project goes on
for so long that the design specification changes while you work!
This is very typical for accounting/materials/business applications.
GnuPG is also like that - new algorithms are added, new interfaces,
some code gets redesigned... it is not exactly a one-time job to be
done on December 17th and that's it. There are so many possible
extensions and improvements (like interface to a biometric scanner,
to name just one) that people will be hacking the code for long,
long time.

Said that, RUP remains a very solid method of development when large
teams are involved. You can not just email 200 developers asking them
to change all their code because you alone decided that this will be
"good". Investment in RUP process is dwarfed by stable, predictable,
manageable design process. XP, on the other hand, seems to be better
for small to medium sized projects that are "brainstormed" by few good
programmers. Losses on redesign are relatively low there and the
quality of the final product may be better. But, as usual, it all depends
on uncountable number of other factors... you can't just compare a
hardwired robot and a bird. On average they have probably the same IQ,
but how helpful that is? Robot is better on assembly line; the crow will
learn all your tricks and find a hidden food.

Cheers,
Dmitri


__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/