Re: [cpp-netlib-devel] Project/release manager

[Peter S. <si...@cr...>]

Hi Glyn,

first of all, thank you for the effort to revive the cpp-netlib
project. I don't believe that a free software project needs
leadership, but every non-trivial effort needs coordination because
it is impossible for everyone to think about everything in great
detail.

Many contributors to this list are extremely knowledgeable and have
already written significant amounts of code. A problem is that we,
the people who spent weeks and months of our spare time to write
that code, have a tendency to think "I need my code polished and
tested so that it can become part of Boost". This perceived honor is
our egoistical motivation for participating in an altruistic effort
-- a free software project.

It's only natural, but it is a problem, because we should not be
thinking about our code or code we already have, we should ask
ourselves: what do the users want? What does an everyday C++
programmer want to do with the Internet, but can't, because it is
too difficult? What kind of functionality would he or she love to
find in our library?

The ability to perform an HTTP request with a handful of function
calls is obviously appealing. The ability to parse the message text
into RFC-compliant data structures is a part of that task -- so are
the pretty-printers to format the data structures into message text.
It should be possible to performed any number of simultaneous
requests asynchronously. Some notion on keep-alive support is
required, and a connection cache might even take advantage of that
transparently.

To offer this kind of functionality would be quite a challenge. To
get there, we need to agree on the user API. Once we know what the
user's program will look like when he uses our code, we can divide
this huge problem into a number of fairly small problems, assign a
volunteer to each of those sub-tasks, and start hacking away.

I feel the best approach to jump-starting this mailing list is to
work out a readable document that describes our goal. A collection
of random classes just doesn't do it. You seem to have a high-level
perspective on all those problems, Glyn. I feel that qualifies you
very much for the task of coordinating this effort. Us in-depth
experts all too frequently find it hard to let go of all the detail
and look at the big picture. Someone has to, or this project won't
go anywhere.

Anyway, that's my perspective. Thank you for sharing yours.

Best regards,
Peter