[conspire] July schedule posted

[Tony Godshall]

Best Regards.
Please keep in touch.
This is unedited.
P-)


On Tue, Jul 7, 2009 at 8:03 PM, Rick Moen <rick at linuxmafia.com> wrote:

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


Sorry.  I took "Again, I'm well aware of that feature of the vCalendar /
iCalendar specs." as "stop lecturing me".  It's hard to judge how much to
say about things.  Be too general and risk misunderstanding.  Bet to
specific and come across as lecturing, pedantic.  Some of the information
was more novel to me than it was to you.

Hey, the rest of you tired of our navel-gazing yet?  ;-)


> 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, certainly better than someone who merely skimmed and picked (me).

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

Yes, I understand.


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

OK.  Good to see that we are not so far off the same page.


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

Didn't connect the dots.  Sorry.

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

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.


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

Good point.  It was only speculation.  I suppose one could actually read the
code rather than guess.


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

OK.  I assumed a higher rev of the code would handle the latest rev but no I
didn't bother to check.

Perhaps it's just error-handling to handle more and more oddities as more
people implement intrepretations of the spec.

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

Didnt catch that bit.  Yeah, that sucks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20090708/12f60407/attachment.html>