Boost logo

Boost :

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2002-04-01 19:25:03


Beman Dawes wrote:

> Dave's right. Normally we could do some private experimentation,
> learning as we go, and then go public when a service is working properly.
>
> But where Boost doesn't have our own server or Internet connection, we
> can't do that. It is very frustrating.

I don't think that things are that bad: It should be possible to set up

an nntp server on an arbitrary UNIX box, if necessary disconnected from
the internet, and play with the necessary scripts there. To test posting
to the real thing, alt.tests can be used. Also, there are several
packages for moderation available.

The only tricky part is the actual official newsgroup creation: If it is

desired to have it in comp.*, a RFD and CFV are necessary which is
likely to take something like three month (the minimum time for each is
one month; well, that is, it was that way I haven't checked whether the
times are changed). This should be plenty of time to set up the
moderation software.

I propose that the general setup is discussed in a smaller forum (eg. at
the next Committee/Boost meeting) and the results made the RFD which is
also subject to discussion. As far as I understood the general
discussion so far, the cornerstone will be soemething like this:
- A moderated forum is created (eg. comp.lang.c++.boost); possibly
   more than one forum is created eg. ...boost.developer and boost.users.
- For a list of users (maintained automatically or by a moderator)
   articles are automatically approved. If no manual moderation shall be
   made, registration can be required ("normal" submission are rejected
   with a text directing the author to the registration).
- To reduce propagation delay, the newsgroup is mirrored to a mailing
   list (there is no additional moderation delay due to automatic
   moderation).
- The moderation address is subscribed to the mailing list to make the
   process bidirection; of course, articles submitted via the mailing
   list shall not be sent to the mailing list again (this can be done by
   using a special address for the submission forom the mailing list).
- E-mail addresses shall be mangled to prevent address harvesting. This
   one is a little bit tricky due to e-mail addresses in the message
   body. Also, the whole subscription idea is somewhat based on people
   using known e-mail addresses, at least when posting via UseNet.

Implementing this shouldn't be too hard if Perl, a commandline program
posting an article, and a commandline program sending an e-mail are
available. I can provide the necessary scripts but I would like help
from someone who is at least willing to review the scripts (I'm not a
Perl expert...). Concerning later administration, I'm willing to do this
also but definitely not alone: I'm sometimes away from my computer and
there should be someone else knowing what to do in case of problems
(typically, this should be resetting a daemon but unexpected things also
go wrong occasionally...).

-- 
<mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk