Sounds like you're over reengineering reimplementing a wiki.

Hmmm, a wiki. We do have Twiki, but I don't think there's anyone here (that I know of) who knows how to set up the permissions properly.

Also, since the idea is that it will work in an emergency, it has to be as simple as possible. If I write a CGI script, only two machines have to be up for it to work. Use a databse and that number goes up by 50%. Not sure about the Wiki. Also have to check if we have the DBI::* modules installed. Thanks again for the replies. ++

Terrence

_________________________________________________________________________________

I like computer programming because it's like Legos for the mind.

My employer was using swiki for awhile, which does not use a database backend - instead it uses xml files. The idea was to keep it as simple as possible and remove dependencies and simplify administration. Worked well until the machine went down because of a runaway script and the XML files were mangled somehow. We have since switched to using a different wiki, with a database backend.

Issues like file/record locking and the ability to gracefully handle an unexpected shutdown are things that databases excel at. I would recommend taking advantage of this.

If the DBI modules are not installed on the server you can always install them to a local directory and define the PERL5LIB environment variable.

As for reducing the number of machines involved, why not run the database on the same machine as the web service?

In my opinion you should use a database to store the information instead of text files. It's less work ultimately, and won't cause badness if two people save the same item at once.

As for the web interface you should use a templating system instead of writing inline html. It's much cleaner and easier to maintain. Your needs sound fairly basic, so you can get away with using HTML::Template. You should be up and running with it in under 30 minutes, and will never write inline html again. If you're adventurous then Template Toolkit is a more robust option.

As for the perl code to control everything there are a number of frameworks for encapsulating common design patterns. For example, CGI::Application provides the common dispatch script behaviour.

www.whatever.com/Division1/wb/sectionmnemonic

The creation of the Division whiteboard will key off of the subdirectory list in the 'wb' directory. So to add a new section or delete one, just create/delete a folder.

So we're talking one script plus two files per section. Seven sections means 15 files for this system. not too bad, eh?

Erm, I clicked too fast. What was your question?

$,=42;for(34,0,-3,9,-11,11,-17,7,-5){$*.=pack'c'=>$,+=$_}for(reverse s
+plit//=>$*
){$%++?$ %%2?push@C,$_,$":push@c,$_,$":(push@C,$_,$")&&push@c,$"}$C[$#
+C]=$/;($#C
>$#c)?($ c=\@C)&&($ C=\@c):($ c=\@c)&&($C=\@C);$%=$|;for(@$c){print$_^
+$$C[$%++]}
[download]

Basically, what do you think of the design? Of using text files vs. XML vs. a db?

And imp, as for you, young man, I normally would probably take advantage of the postgres server that we have here, but a) admin is controlled by someone else and b) it introduces another dependency. The sql box doesn't have a great history of reliability or response to customer queries (get it? queries? huhuhuhuhuh). If this were for day-to-day use, yeah, I'd probably use a db. But files are just as easy to me now that I've used Text::CSV::Simple a few times and it's one less dependency on an externality when the proverbial excrement hits the fan. I guess delevopment time also factors in.

_________________________________________________________________________________

I like computer programming because it's like Legos for the mind.

Basically, what do you think of the design? Of using text files vs. XML vs. a db?

Wrap it all up behind DBI as a general interface layer and you'll be able to trivially (just change the DSN) switch between them ... so, for example, you can start with text files because they're easy to create .. or start with the db and if there're admin issues, switch to text or xml..
See DBD::CSV, DBD::AnyData, DBD::Pg, etc ..

(additionally consider putting Class::DBI or DBIx::Class or some other db abstraction layer on top of DBI)

UPDATE: So I've consulted with the guy who runs out web server and he recommended that the whole thing be CGI--the displayer and the editor. That's cool by me. I may put all the data into one big file (now that starts calling for a true DB, big time, cos then the display page has to be able to pluck just the appropriate entries based on a combination of their choices and their default unix group). Anyway, been busy with busywork, you know stuff that isn't really that creative. But this is on priority.

_________________________________________________________________________________

I like computer programming because it's like Legos for the mind.

So it turns out there is a PostgreSQL database that has tables that will allow me to extract a list of all user IDs, and real names that are members of any given group. From there I can do an `id -Gn` for the rest. I plan to store everything in a local SQLite database for editing and manipulation, and have a cron job that periodically syncs the databases, or more likely, looks for differences in the lists and notifies me.

_________________________________________________________________________________

I like computer programming because it's like Legos for the mind.

Here's what I have so far. We're going to test multiple simultaneous users today and then test with probably a few dozen users on Saturday.

Some things in the comments and variable values may be inconsistent; I don't want to give too much away about where I work.

Terrence

Edited by planetscape - added readmore tags