[conspire] July schedule posted
rick at linuxmafia.com
Wed Jul 8 16:05:15 PDT 2009
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
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
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
> 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. ;->
More information about the conspire