RE: Ringlink feature requests

["Pamster" <pam@pamster.com>]

I think maybe #2 is that the emails for submissions, removals, etc. could be
sent to more than one person.
Pam
> -----Original Message-----
> From: owner-ringlinklist@1-host.com
> [mailto:owner-ringlinklist@1-host.com]On Behalf Of Gunnar Hjalmarsson
> Sent: Monday, October 30, 2000 7:03 PM
> To: ringlinklist@gunnar.cc
> Subject: Re: [ringlinklist] Ringlink feature requests
>
>
>
> Hi Dave,
>
> Thanks for your suggestions. My comments follow.
>
> > 1) Make Ringlink runable, and without issuing any warning messages,
> > when the -w option and the "use strict" pragma are specified.
> > Every reference I've seen on Perl strongly recommends this for all
> > Perl CGI scripts. (I've heard that it may compromise security to
> > leave the -w option in a production script, but it should at least
> > be used in pre-release testing of the scripts.)
>
> Please note that Ringlink is my first program worth mentioning, and I
> wrote it without local and/or telnet access to Perl. I guess that there
> is no Perl reference author out there without such access... (For that
> reason, I have built in error messages in a slighly different way than
> you normally see in the tutorials, making them stop the program and
> display the error messages on the screen.)
>
> Thus I have neither the knowledge/experience nor the equipment to do
> what you ask for. But if anybody who has reads this, please feel free to
> do whatever you find necessary to detect possible problems with
> Ringlink. After all, Ringlink is an open source project.
>
> Btw, what kind of errors are you worried about, considering the fact
> that Ringlink seems to work fine?
>
> > 2) Add capability for automatic emails sent by Ringlink to be BCC-ed
> > to a provided list of email addresses.
>
> If you mean tools to facilitate emails to all the ring members, it's on
> the project list.
>
> > 3) Add control for "turning off" the Ringlink script.  This would
> > be useful when backing up or restoring the data files, or when
> > making changes to the configuration.
>
> Good idea, but I have to give it rather low priority right now.
>
> > 4) Encode passwords (using Perl's one-way encryption function
> > crypt())? Might be overkill.
>
> I thought about it at an early stage, and decided not to. And I haven't
> changed my mind yet, see
> http://www.gunnar.cc/ringlink/mailarc/msg01003.html
>
> SSL might be a way to increase security in this respect for those who
> thinks it's important. I'm playing with it right now on my own
> installation; please feel free to study the demo ring for instance.
>
> But whatever you do, you always end up at the necessity of: regular
> backups!
>
> > 5) I think the list-sites function lists the sites starting at a
> > random site.  This might be beneficial for first-time visitors to
> > the ring, but it could be annoying for someone trying to
> > systematically view the sites in the ring.  I can't think of a good
> > solution, though, other than using an approach like the old webring
> > system.
>
> The list starts with a random site if no site ID is specified; if it is,
> it starts with the specified site. So if the site ID is specified in the
> links in the HTML code (which it should be, for this and other reasons),
> it should be easy to explore a ring systematically.
>
> I'm very pleased with the way the list-sites function works, and can't
> think of changing it to the WebRing approach. The Ringlink approach,
> which conceptually implies that the ring has no beginning or end, leads
> to the traffic being much more fairly distributed.
>
> > 6) Please add inline and/or external documentation to the scripts :)
>
> In my opinion, the structure, subroutine names and variable names
> normally give you a good picture of how the program works (provided that
> you have some Perl knowledge, of course). I don't say that additional
> comments would be redundant, but I'm not ready to spend time with it
> right now. Btw, maybe this is an appropriate task for someone else but
> me. Any volunteer?
>
> / Gunnar