[conspire] July schedule posted

[Tony Godshall]

On Wed, Jul 8, 2009 at 11:39 AM, Rick Moen<rick at linuxmafia.com> wrote:
> Quoting Tony Godshall (tony at of.net):
>
>> I'm sorry I seem to not be making myself clear.
>>
>> Something that takes seconds instead of fractions of a second wouldnt seem
>> to matter much if you have to use it only rarely, like, say, to create the
>> static site.
>
> Two problems, here.  First, I don't know what you are talking about,
> when you say "create the static site".  I'm not building Web pages from
> iCalendar; I'm just seeking to offer iCalendar as a download.
>
> Second, I'm unclear on how PHP iCalendar would be useful in "creating
> the static site", even if I were doing that.  That codebase appears to
> offer the remote Web user a variety of views of one or more iCalendar
> file.
>
> So, yes, either you're not making yourself clear or I'm having a severe
> parsing problem, because I have not a clue what you're talking about,
> here.
>
> [PHP iCalendar 2.31:]

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?

A multi-second dog-of-a-program is much less of a dog if it is
executed (and niced) rarely rather than executed on demand.

Geez, I really didn't think I was *that* bad a communicator.

Must be those "weird assumptions"

I know dynamic websites are all the rage and lots of people just
assume PHP's the way to go but static ones are way more scaleable (not
to mention secure).

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.

>> Perhaps it's just error-handling to handle more and more oddities as more
>> people implement intrepretations of the spec.
>
> Speculation, and in any event, rather beside the point:  Unless I can
> find a way to make it cease to suck, the point is that it sucks.

A rare nice-niced suck is much less of a problem than a
suck-when-your-are-waiting-for-it suck.

An occational backgrounded only-when-things-changed suck is much less
of a problem than a suck-at-high-priority-everytime-someone-wants-it
suck.

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

But no, anyway, as you said, not only does it suck CPU but it also
sucks in terms of parsing more poorly.

Fine.  Settled.  OK.

Tony