cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon is not gump!
Date Tue, 29 Jun 2004 18:46:27 GMT
Antonio Gallardo wrote:

> I don't talked about forking. My POV is, why to see the code? It is not
> enough to know that a 3rd party lib is broken. Contact the right community
> and check if there is already a patch for the problem? IMHO it is easier
> than debug it yourself. The chances a fix is there is very high.
> 
> I often prefer to google for a bug before starting to wet my hands. Maybe
> I am very lazy! ;-)

hmmm, consider this scenario: you are asked to build a system, say, for 
the government, that has to support the pension system or the IRS.

This cocoon application was built out of an official release, everything 
documented, legally certified, all text written and such.

This application runs for 15 years, then, one day, a change in the 
underlying dependencies (java or whatever) affects it in such a way that 
it can no longer work.

You are hired again to fix it.

You find out that this "jurassic" cocoon version depends on technologies 
that are no longer available, their communities folded, the CVS archived 
or lost in a disk crash or in OSDN bankrupcy.

What do you do?

A decompiler will be your best friend, not google. Google might give you 
the solution, but without the code how to you change it? re-assemblying 
the bytecode by hand?

Or you might want to kiss Sylvain if the source code was distributed 
along with the binary code ;-)

When I say "along" it doesn't mean "inside", even if I completely agree 
with Sylvain that having the code inside with the bytecode in the jar 
makes the most natural sense.

Carsten is afraid of having to deploy a few more Mb of stuff, I think 
the first time he is hit by the above scenario he'll change his mind 
rather quickly and a few Mb will not be such a big deal of a price to 
pay to sleep well at night.

My point is: do *not* make the assumption that the CVS will be there 
when you need it. It won't be. Solid working software has the tendency 
to work for decades before requiring fixes. And people have a tendency 
to change jobs, ideas and interests much faster than working software 
requires fixes.

And information has a notoriously bad habit of getting corrupted, or 
lost and people (including myslelf!) have a notoriously bad habit of 
still considering digital storage capacity as a scarce resource and are 
maniacs of cleaning up and very bad at forecasting the need for 
information that today appears useless.

I guess that working in a library does change your perspectives on those 
things a little bit ;-)

Especially when your boss sings the digital preservation anthem every 
other day ;-) [and for a good reason, I must say!]

-- 
Stefano.


Mime
View raw message