[conspire] July schedule posted

[Rick Moen]

Quoting Tony Godshall (tony at of.net):

> OK.  I'm sorry I overcommunicated there.  Sometimes I do that.
> It helps me think.  I don't mean to demean.  You probably understand
> them much better than I do.  Since this entire conversation is CC'd
> from the beginning to conspire@ it makes sense to err on the side
> of clarity even if it may seem pedantic to you- perhaps others can
> assist or learn.  I'd probably assume more of a word to the wise
> kind of attitude if it were private and we hadn't alread a bit of
> miscomm.

Believe me, I took no slight, and didn't perceive any attempt to demean
(not that there's anything demeaning about being said to not know a data
format).  Like you, I'm just trying to be really clear, in part because
we're writing for the archives.  So, when I said I was aware of that
feature, I really meant exactly that, and no more.

It's an overstatement to say I know the spec well.  I _did_ know the
spec well, some years ago when I wrote about it, and it was the coming
thing.


> Well, now I'm going to actually have to pay attention to the events
> I'd skimmed past in the past.

Nothing all that special.  http://linuxmafia.com/bale/holidays is what I
work from, containing the candidate holidays that I _may_ put in there
at times.

The long "BALE is a personal expression" passage you just plowed through
was, I hope you realise, directed primarily at a number of other people
who can't seem to get straight that it's not a public utility, and that
if they want to set up a variant elsewhere with contents more to their
liking, I'll gladly give anyone a copy of the MySQL schema and PHP and
Python that drive the site.  (Deirdre has permitted her work to be
open-sourced.)  So, that part was really not aimed your way, mostly.


> So you don't want to switch the CABAL calendar to something else?

It would be sensible to adapt PHP from the BALE page (changing the SQL
query to grab just CABAL events), and replace the static calendar table
in the CABAL page, wouldn't it?  I just haven't gotten around to that --
and updating the static table is so fast and trivially easy that I just
haven't bothered.


[PHP iCalendar:]

> Oh, and your complaining about how long it took to come up and that
> you'd stick with the old version was supposed to tell me you *weren't*
> considering it for production use?

What might have told you that was the part where I said, early in the
converstion, that it was just something I'd had around to play with.


> > PHP iCalendar 0.9.4 is perfectly tolerable, FWIW.  2.3.1 appears to be
> > ghastly.
> 
> Well, yes, perhaps it has to parse the more the complicated
> options of a higher rev of the standard.  Or maybe it's prettier.
> But what I don't see is why you care so much if it takes a
> second or five if it's only done statically after an edit.
> Premature optimization IMHO.

1.  It's dog-slow every time -- as you can see for yourself.  I see no
reason to think that it's slow only once after an edit.  To the
contrary:  That's the exact opposite of what I see.

2.  It's dog-slow even when it parses only bale.ics, which implements no
"complicated options".  

3.  Both releases process vCalendar 2.0 data, which is a mature spec and
is what iCalendar files are made of.  There is no "higher rev of the
standard".

4.  I care because I'm quite fond of 0.9.4, so it's distressing that
2.3.1, so far, acts like a piece of junk, with terrible performance and
misparses of HTMLised fields within the il file.