In reply to: "How often do you want to get nagged?"
On 4/13/07, Ted Roche <[EMAIL PROTECTED]> wrote:
There's a parallel effort in place to replace TWiki with MediaWiki.
"Effort" might be a bit much. :) There's a few people (I'm one of them) who have advertised a preference to MediaWiki, and a few people who have said they've setup MW before and might be able to help out. That's about as far as it's gone. :)
When/if that happens, I'd like to look at Calendar plug-ins or add-ons to MediaWiki ...
My experience with wiki's -- in particular our experience with the calendar plugin for TWiki -- leads me to believe that looking for a calendar that plugs in to a wiki is a case of hammer myopia[1]. Wiki's are fundamentally unstructured, free-form text for human beings. Calendars are fundamentally high-structured, with fields, syntax, constraints, algorithms, and the like. I think we're better off finding a really good calendar tool, rather than settling for a poor calendar just because it's bolted on to the wiki. [1] "When all you've got is a hammer, everything starts to look like a nail."
... fit-and-finish, wedging it into our existing system ...
IFRAME's, TWiki includes, and things like that should let us wedge it into the home page display. Alternatively, we could make the home page a separate entity, outside of TWiki (it used to be that way, way back when). If looks like we just stuffed a calendar into our home page, that's okay, because that's basically what we want. :)
... adding it to the LogWatch list ...
LogWatch on liberty already spews tons of crap that I haven't taken the time to learn how to fix. And as far as I know, I'm the only one who has expressed interest in "reading" any of the server's system mail.
... arranging for a backup ...
The server is already backed up with rsync snapshots nightly, thanks to Matt Brodeur. All we have to do is make sure the database does a nightly dump to a file that gets backed up. I'm sure someone who knows enough to set-up MySQL properly knows how to do that. (I hope.)
retaining some of the functionality we've grafted onto the wiki for attendance tracking ...
Edit the calendar entry /post facto/ and punch in the attendance count.
archival history
Don't delete old calendar items.
links to notes, etc...
Pick a calendar package that lets us embed/attach hyperlinks. The other objections I can come up with are: (1) One more software system to install and maintain. Oh well. ROI is there. (2) We've had to have someone "on staff" to take care of the care and feeding of MySQL. I'm pretty sure we have several we can rope into volunteering. My understanding is that MySQL is pretty low-maintenance. (3) There would be a discontinuity between the existing history we have at PastEvents and the new history which would be in the calendar. I'm willing to just draw a line and say "Older than this date, look on the wiki; newer, look in the calendar". (4) Separate user auth database for calendar. Oh well. Life is hard. If it bothers us that much, pick something that can use Apache authentication, and we'll hook it into TWiki's htpasswd file. Or we'll hook TWiki into it. Or both into RADIUS or something. Or just live with it. Everybody's already got a brazilian accounts to keep track of for stupid web sites; this will just be one more. One more advantage of not tying the calendar to the wiki: We can switch wiki's without breaking the calendar. -- Ben _______________________________________________ gnhlug-org mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-org/
