<br clear="all"><br><div class="gmail_quote">On Mon, Jul 6, 2009 at 7:37 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">I wrote:<br>
<br>
> Hell, maybe I should just make a daily cronjob to run that Python script<br>
> as-is, with a local parse on /var/www/cabal/index.html, and a wget fetch<br>
> of the output of <a href="http://linuxmafia.com/bale/index.php" target="_blank">http://linuxmafia.com/bale/index.php</a> .  Buggy and a<br>
> little odd, but arguably better than nothing.<br>
</div></blockquote><div><br>If you want to keep editing the calendar as HTML, I guess.  I'd argue it's simpler to maintain the calendar in a more vim-friendly format.  But I don't want to start a editor-religion war on this list.<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;">I see two obstacles worth mentioning:<br>
<br>
1.  Omitting (or rather saying "bad start: 0" for) events with<br>
non-numeric or null placeholder data in the start-time / end-time<br>
fields.   It can't be that difficult to use whatever iCal understands to<br>
mean "beginning of day" and "end of day".<br>
</blockquote><div><br>Yeah, those events looked like they were coming from elsewhere anyway (canned calendars from ??) so it didn't make much sense to try to deal with them in the time alloted<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;">

2.  Breaking horribly on calendars crossing the year boundary -- and in<br>
general not handling years.<br>
<br>
<br>
The root cause of badness #2 is that the BALE and CABAL pages don't<br>
bother to mention years.  They're designed to be parsed by humans,<br>
who (generally) know what year it is, and that "January" events seen<br>
near the end of a calendar that starts in November or December are next<br>
year.<br>
<br>
Tony's script went for the low-hanging fruit by saying "just assume<br>
2009, for now" -- which is great for prototyping, but needs to be fixed<br>
for production.  I have no idea how, offhand.<br>
</blockquote><div><br>Yeah, well, again I intended it as a one-time one-way hack.<br> <br>If we wanted it to be production, I'd clean up old events and then do a heuristic that says any month before this one is next year.<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;">

On the bright side, PHP iCalendar solves a bunch of other problems.<br>
My installed version, 0.9.4 beta, is ancient.  The current 2.31 release<br>
(notably) supports the user's choice of RSS version 0.91, 1.0, and 2.0,<br>
neatly sidesteps that religious issue.</blockquote><div><br>Ah, RSS is part of the spec?  That makes it more complicated.  I'd say calendars are specialized enough you'd want something that can read icalendar/vcalendar instead.  But then again, if someone already wrote a good tool that supports that, OK, cool.  I'm not up on the RSS wars and not particularly sure I want to be.  Sounds like a huge time-sink.  (timesync, heh)<br>
</div></div>...<br><br>