[conspire] July schedule posted

[Rick Moen]

Quoting Tony Godshall (tony at of.net):

> What I've been trying to say is that if I was doing it, I would
> generate HTML and .ics statically build the HTML and iCalendar content
> with PHP on demand.  I stated it explicitly when I was speaking about
> generating the HTML from the iCalendar and of course you set me right
> that you have not intent on doing that and of course the same would
> apply when generating .ics and HTML from mysql.  I.e. anytime you edit
> the master mysql event database, I'd have a script run automatically
> that generates corresponding ics and HTML.  And I'd name them
> something like blah-blah-blah.generated.html and
> blah-blah-blah.generated.ics (but that's just convention to remind
> myself not to edit them).  Thus the dog-of-a-program icalendar-2.31 is
> an issue only once-upon-a-change rather than upon-every-access.  Then
> it can take seconds or even minutes to run and who cares?

Aha.  If you'd prefaced your earlier post with "Note:  The following
paragraphs assume you're intending to rearchitect BALE to lose that
dynamic PHP stuff and serve up script-generated static-HTML pages", I'd
have understood you the first time.

However, such rearchitecting by yr. humble servant, given current
workload, would probably cost me my ragged remnant of sanity -- and I'm
nostalgic about that remnant.  ;->

I share -- in spades -- your leeriness about dynamic sites and
overengineered software.  Serving up script-generated output rather than
dynamic pages is something I often recommend, in fact.  For example,
it's the only halfway sane way to use AWstats
(http://www.debian-administration.org/articles/85), as its default
dynamic-reporting mode does _no input validation_, and thus is a
hopeless security nightmare.

But, anyhow, to implement that idea in the present context, I'd have to
rearchitect BALE.  I could create a Makefile that somehow runs the PHP
interpreter locally on linuxmafia.com, munches an autobale.php file,
does necessary MySQL queries and spits out the resulting output to 
/var/www/bale/index.html, along with presumably a bale.ics file
somewhere if/when I cajole PHP into doing that.  Then, any time I 
used any MySQL tool to change events data, I'd have to remember to
re-run /usr/local/bin/makebale, which does the necessary voodoo using
said Makefile.

All of which is -- what's that slightly sardonic expression? -- a 
"Simple Matter of Programming" or SMoP.   In other words, "I have a
great idea, Rick.  And why don't _you_ do a lot of work to implement
it?"

I assume you see my point.

I'm not saying it's not a reasonable suggestion.  I'm just saying that 
today just isn't the day that I rush out and short myself further on
sleep in order to implement it.

If you were to hand it to me, working and debugged, that would be a
different matter (but one I certainly am not asking for).  But the fact
of the matter is that BALE _works_ at present, and it's just not a
priority within _my_ work schedule to rearchitect it to convert it to
serving static-HTML script output.

> Heck, speaking of dogs, benchmark any php-supporting webserver
> sometime against something like thttpd or khttpd.  It's like the
> difference between interpreted BASIC and cat.

But guess what?  My entire Web server has been bottlenecked on aDSL
bandwidth for the past eight years.  I could be running TUX, thttpd,
Caudium, fnord, medusa, Lighttpd, Boa, or friggin' Zeus Web Server _and_
lose the PHP on BALE, and it wouldn't make a damned bit of difference to
site performance.


> I'd explain further but I'm not sure what aspect you are finding confusing.

Well, I _did_ find confusing your unilaterally transforming a discussion
of how best to export iCal into one about how to rewrite BALE as a
script-generated static page -- but I eventually got over it.  ;->