Boost logo

Boost :

Subject: Re: [boost] [proposal] The Maintenance Effort
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-05-26 13:08:13

I've been following this discussion with some interest. I feel it's moving
in the right direction.

There is one thing I wonder/worry about.

I've created a couple of interactive websites from time to time. It has been
sometime since I've done so, so I'm way out of date with the latest tools
and techniques. I created these sites with relatively simple cgi scripts
written in perl. These two sites were created about 15 years ago and have
worked without problem for all that time. I've had to make a few tweaks
every couple of years to keep things humming. So although not as "slick" as
many current options, they have low maintainence and provide all the
functionality I require. This is bottom line for me.

In the intervening time, there have been a myriad of tools created to do
this job "better". Also the number of libraries available as perl scripts
is much, much larger. I've experimented with other method such as
FrontPage, ASP, very occasionally to see if I was missing something. The
only thing that I think I might use if I were to do this again is

I am very skeptical of "fancy tools". They tend to make things "simpler" by
hiding how things work. The tools look great when you demo them but when
you actually try to use them you find yourself trying to "trick" the tool
into doing what you want. Eventually users catch on to this and then become
customers for the next "solution". It becomes an endless cycle of adding
"cool" features then spending a lot of time to keep them working. This same
problem infects all of modern life. The VCR mentality has spread like a

The current concrete example is the website which uses a few of
these "fancy" tools and has become hard to extend in the way we want.

Soooooo ..... Just one man's opinion that the focus on tools is overdone. I
would like to see a discussion about the structure of a "new" website before
getting into the "tools". Of course I said most of what I wanted to say
about this subject in our discussion regarding this subject at BoostCon. At
that point, I sketched out something that could be done without amending But now that this cat is out of the bag, I'll offer my two
    pages about boost ( basically static pages)
    library index
        Review/accepted libraries
            Alphabetical list
                links to library pages
            By subject
                links to library pages
        Submitted/accepted candidate libraries
            Alphabetical list
                links to library pages
            By subject
                links to library pages

Each library page - similar to what I presented as an example - see
This page would be mostly links to deployment. issue tracking, forums/list.
That is, the implemention of each of these aspects would be left to the
developer. Some libraries need only the simplest of discussions - e.g.
state_saver, Others need the full blown Track or similar system.

The lack of a "unified" system will be found to be off putting to some -
but this methods lets Boost evolve as necessary.

Robert Ramey


Boost list run by bdawes at, gregod at, cpdaniel at, john at