<br clear="all">Best Regards.<br>Please keep in touch.<br>This is unedited.<br>P-)<br>
<br><br><div class="gmail_quote">On Tue, Jul 7, 2009 at 8:03 PM, Rick Moen <span dir="ltr"><<a href="mailto:rick@linuxmafia.com">rick@linuxmafia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Quoting Tony Godshall (<a href="mailto:tony@of.net">tony@of.net</a>):<br>
<br>
</div><div class="im">> OK. I'm sorry I overcommunicated there. Sometimes I do that.<br>
> It helps me think. I don't mean to demean. You probably understand<br>
> them much better than I do. Since this entire conversation is CC'd<br>
> from the beginning to conspire@ it makes sense to err on the side<br>
> of clarity even if it may seem pedantic to you- perhaps others can<br>
> assist or learn. I'd probably assume more of a word to the wise<br>
> kind of attitude if it were private and we hadn't alread a bit of<br>
> miscomm.<br>
<br>
</div>Believe me, I took no slight, and didn't perceive any attempt to demean<br>
(not that there's anything demeaning about being said to not know a data<br>
format). </blockquote><div><br>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.<br>
<br>Hey, the rest of you tired of our navel-gazing yet? ;-)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Like you, I'm just trying to be really clear, in part because<br>
we're writing for the archives. So, when I said I was aware of that<br>
feature, I really meant exactly that, and no more.<br>
<br>
It's an overstatement to say I know the spec well. I _did_ know the<br>
spec well, some years ago when I wrote about it, and it was the coming<br>
thing.</blockquote><div> </div><div>Well, certainly better than someone who merely skimmed and picked (me). <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> Well, now I'm going to actually have to pay attention to the events<br>
> I'd skimmed past in the past.<br>
<br>
</div>Nothing all that special. <a href="http://linuxmafia.com/bale/holidays" target="_blank">http://linuxmafia.com/bale/holidays</a> is what I<br>
work from, containing the candidate holidays that I _may_ put in there<br>
at times.<br>
<br>
The long "BALE is a personal expression" passage you just plowed through<br>
was, I hope you realise, directed primarily at a number of other people<br>
who can't seem to get straight that it's not a public utility, and that<br>
if they want to set up a variant elsewhere with contents more to their<br>
liking, I'll gladly give anyone a copy of the MySQL schema and PHP and<br>
Python that drive the site. (Deirdre has permitted her work to be<br>
open-sourced.) So, that part was really not aimed your way, mostly.<br>
<div class="im"></div></blockquote><div><br>Yes, I understand.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
> So you don't want to switch the CABAL calendar to something else?<br>
<br>
</div>It would be sensible to adapt PHP from the BALE page (changing the SQL<br>
query to grab just CABAL events), and replace the static calendar table<br>
in the CABAL page, wouldn't it? I just haven't gotten around to that --<br>
and updating the static table is so fast and trivially easy that I just<br>
haven't bothered.<br>
</blockquote><div><br>OK. Good to see that we are not so far off the same page.<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
[PHP iCalendar:]<br>
<div class="im"><br>
> Oh, and your complaining about how long it took to come up and that<br>
> you'd stick with the old version was supposed to tell me you *weren't*<br>
> considering it for production use?<br>
<br>
</div>What might have told you that was the part where I said, early in the<br>
converstion, that it was just something I'd had around to play with.<br>
<div class="im"></div></blockquote><div><br>Didn't connect the dots. Sorry. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<br>
> > PHP iCalendar 0.9.4 is perfectly tolerable, FWIW. 2.3.1 appears to be<br>
> > ghastly.<br>
><br>
> Well, yes, perhaps it has to parse the more the complicated<br>
> options of a higher rev of the standard. Or maybe it's prettier.<br>
> But what I don't see is why you care so much if it takes a<br>
> second or five if it's only done statically after an edit.<br>
> Premature optimization IMHO.<br>
<br>
</div>1. It's dog-slow every time -- as you can see for yourself. I see no<br>
reason to think that it's slow only once after an edit. To the<br>
contrary: That's the exact opposite of what I see.<br>
</blockquote><div><br>I'm sorry I seem to not be making myself clear.<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
2. It's dog-slow even when it parses only bale.ics, which implements no<br>
"complicated options".<br>
</blockquote><div><br>Good point. It was only speculation. I suppose one could actually read the code rather than guess.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
3. Both releases process vCalendar 2.0 data, which is a mature spec and<br>
is what iCalendar files are made of. There is no "higher rev of the<br>
standard".<br>
</blockquote><div><br>OK. I assumed a higher rev of the code would handle the latest rev but no I didn't bother to check.<br><br>Perhaps it's just error-handling to handle more and more oddities as more people implement intrepretations of the spec. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
4. I care because I'm quite fond of 0.9.4, so it's distressing that<br>
2.3.1, so far, acts like a piece of junk, with terrible performance and<br>
misparses of HTMLised fields within the il file.<br>
<div><div></div><div class="h5"></div></div></blockquote><div><br>Didnt catch that bit. Yeah, that sucks.<br> <br></div></div><br>