[conspire] July schedule posted

[Tony Godshall]

On Wed, Jul 8, 2009 at 4:05 PM, Rick Moen<rick at linuxmafia.com> wrote:
> 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.

Doctor, it hurts when I do this!

Heh.  You assumed I knew your architecture.  Silly assumption. ;-)

You'd given me only bare outlines.  From what you said it could be
easy or hard to convert.

Now that you've described your existing process more thoroughly I know
it would be a time-consuming bear.

Or I should say, I trust you that that's true because still haven't
seen the internals I don't have the PHP.

But you seem reasonably trustworthy. ;-)


> 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.  ;->

Sure, I understand that


> 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.

Good example


> 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.

Well, how about the python icalendar module i referenced, an example
of which i hacked up for you already.  If you give me a sql dump file,
I'll even add the parse-the-sql-dump bit I left out and see if it'll
actually run.

As you can probably tell right now, I'm a lot more comfortable hacking
python than php, and I'm willing to help.

If you want me to.


> 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.

Or just set up a cron job.  Do you care that much if your changes
come out now or five minutes from now?


> 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.

Sure, well, sometimes it's easier to change to a simpler way and
factor out the existing cruft.  Since I don't know how clean or crufty
your php is (I see the rendered output, remember, not the mysql or the
php) ...

I trust you to be the judge of that

And I'm certainly not asking you to take on a big rearchitecturing
job.  But without access to your internals the best help I can be is
to pop in with hopefully-helpful bits here and there that may help you
do the bits you might eventually want to do.

That's what I've been trying to do anyway.

Sorry if it was confusing.


> 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.

No that's cool.

It's your site, not mine, and I apologize if I gave the impression at
any point I was trying to boss you around.

If you want to drop the subject it here and now that's your prerogative.

But if you want to back burner it and feed me bits here and there to
do that I actually can do, that's cool too.


> 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).

Well, if you give me database dumps and php code, maybe I can do just
that.  Maybe not today or next week, but in the next couple of months.


> 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.

Makes sense.


>> 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.

You point is well taken.

Well, 90% well taken.

5% doubt: if icalendarphp version that takes *seconds* of CPU time to
serve up a small plaintext file will certainly cause noticeable load
if multiple people hit it simulatneously.  And you have to admit that
the BALE is popular.

5% doubt: There is this feature of thttpd where you can tell it to
throttle certain kinds of files.  That way it can still be responsive
even though the connection is saturated.

I.e. software actually can make a difference even where there's a huge
processing power to pipe differential.


>> 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.  ;->

Well, I said that was how I'd do it, several times, premised on the
assumption that you didn't seem to share that static sites work better
than dynamic ones and professing ignorance at the internals of your
system.

Doctor, it hurts when I do this!

Well, stop doing it!

And I explained up front that I'd written a quick one-way hack on that
assumption that that didn't seem to confuse you until later.

But yes, it's good that you got over it once you understood that I
hadn't understood that you have a large and complex php and mysql
structure you'd rather not change...

I didn't think I was being unilateral but you kept sounding like you
didn't understand how the issues you had raised as major issues were
based on certain assumptions so I had to explain them further and
further until I finally understood what your assumptions were.

Anyhow, now that your assumptions and architecture have been a bit
better illuminated we can go back to whatever direction you wanted to
take the conversation discuss before I "unilaterally" derailed the
discussion.

Go back, pick up the thread, pray continue, fine sir, to where you
were before I so rudely interrupted.

Tony