[conspire] July schedule posted

Tony Godshall tony at of.net
Tue Jul 7 11:05:33 PDT 2009

On Mon, Jul 6, 2009 at 7:37 PM, Rick Moen <rick at linuxmafia.com> wrote:

> I wrote:
> > Hell, maybe I should just make a daily cronjob to run that Python script
> > as-is, with a local parse on /var/www/cabal/index.html, and a wget fetch
> > of the output of http://linuxmafia.com/bale/index.php .  Buggy and a
> > little odd, but arguably better than nothing.

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.

> I see two obstacles worth mentioning:
> 1.  Omitting (or rather saying "bad start: 0" for) events with
> non-numeric or null placeholder data in the start-time / end-time
> fields.   It can't be that difficult to use whatever iCal understands to
> mean "beginning of day" and "end of day".

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

> 2.  Breaking horribly on calendars crossing the year boundary -- and in
> general not handling years.
> The root cause of badness #2 is that the BALE and CABAL pages don't
> bother to mention years.  They're designed to be parsed by humans,
> who (generally) know what year it is, and that "January" events seen
> near the end of a calendar that starts in November or December are next
> year.
> Tony's script went for the low-hanging fruit by saying "just assume
> 2009, for now" -- which is great for prototyping, but needs to be fixed
> for production.  I have no idea how, offhand.

Yeah, well, again I intended it as a one-time one-way hack.

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.

On the bright side, PHP iCalendar solves a bunch of other problems.
> My installed version, 0.9.4 beta, is ancient.  The current 2.31 release
> (notably) supports the user's choice of RSS version 0.91, 1.0, and 2.0,
> neatly sidesteps that religious issue.

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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20090707/e2283526/attachment.html>

More information about the conspire mailing list