[conspire] July schedule posted
rick at linuxmafia.com
Mon Jul 6 18:58:59 PDT 2009
Quoting Tony Godshall (tony at of.net):
> OK, so here's a better start (stole some time)
> So far I'm generating stuff like this with the python attached (and
> yes, before anybody starts on the style criticism, this is being
> written under the assumption that it's a one-time-use one-way hack
> with better code being used to regularly build html and hCalendar from
Getting close. Have a look at
That is displaying http://linuxmafia.com/calendar/calendars/bale.ics
within an old version if PHP iCalendar I've had online since forever.
bale.ics is a test run of your t.py (with small fixes), arrived at as
$ wget -O- http://linuxmafia.com/bale/ > /tmp/t
$ cd /tmp
$ python t.py > bale.ics
$ mv bale.ics /var/www/calendar/calendars
Load into PHP iCalendar page... and the software chokes on it, because
it's not a valid iCal file. Examine file, note absence of headers and
footers. Supply mockup-grade faked headers:
:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN
and the necessary footer:
Load into PHP iCalendar page... and note that there are now valid
iCal events, despite all the "bad start: 0" placeholder lines where your
script was not able to parse "-" timestamps for events with no
particular start/stop times (holidays, things that span multiple days,
things that run all day long).
I put the obvious Print statements into t.py.
However, problem: There is null text shown for all of the events.
Compare draft "bale.ics" against other iCal files. Do
":%s/DESCRIPTION: /SUMMARY:/g" on the bale.ics output file, since it
appears that "SUMMARY:", not "DESCRIPTION:" is what gets shown (and to
get rid of the spurious space character after the colon). OK, no longer
And so, we arrive at what looks like a halfway decent iCal file --
albeit one with a badly organised SUMMARY field (which really ought to
have the group's name first, not city first).
OK, I've now fixed _that_ as well: The line that used to return
DESCRIPTION now has:
print "SUMMARY:%s: %s" % (items,items)
I attach the trivially-improved script as ical.py. Thanks for your
efforts so far!
Readers, please note: That was just a test run, to see if we can get
valid iCal at all. That is not production, just test data. In
particular, I am _not_ currently committing to keeping that bale.ics
Obviously, in actual use, "ASSUMEYEAR=2009" is no-go and would have to
be filled in with something that works. A call to "date +%Y" is sort-of
an answer, but you have edge cases with calendars that wrap around the
year end, that need more-intelligent handling.
Also, we'd need to work around that problem of not parsing "-" and just
punting on non-numeric timestamps, by substituting something reasonable.
Like [date]T000100 for a DTSTART just after midnight, and [date]T235900
for a DTEND just before midnight, if I'm reading the spec right.
Also, although I admire the pragmatic way you grab HTML to parse using
wget for prototyping purposes, in production wget'ing input might be a bit
whacked. You're correct that the HTML on the CABAL page's calendar
table is sort-of the same as BALE's -- but that's a matter of
protohistory: I created the CABAL page's calendar by, at one point,
taking the _output_ of BALE (which is PHP) and pulling just the CABAL
entries into a text editor. And then maintaining _that_ flat HTML,
going forward, in a text editor.
There's also something unpleasant with what happens to the SUMMARY
field. Note this field in the "t" file for a CABAL day:
<a href="#cabal">CABAL</a> meeting</strong> at <a
href="../cabal/#directions">Rick & Deirdre's House</a> <a
The "#cabal" and ""../cabal/#directions" are fine _on_ the BALE page,
because they resolve relative to the page base URL, which is
http://linuxamafia.com/bale/ , for which request the Web server sends
http://linuxamafia.com/bale/index.php . However, out of context in
(e.g.) PHP iCalendar, they become:
...both of which are 404.
So, ideally, relative URLs within the SUMMARY field for BALE data would
get dereferenced to http://linuxmafia.com/bale/[relURL], and ones for
CABAL data to http://linuxmafia.com/cabal/[relURL]. Or something.
The ".." is a real headache, but I'm pretty sure it's unique to CABAL
events on the BALE page -- and is an artifact of my knowing that the
BALE and CABAL page files will reliably have a fixed directory
relationship. (If I needed to, I could stop using ".." relative
paths -- but I'm reluctant to stop using the others, as they are useful
within the BALE page.)
But anyhow, that problem plus the "-" timestamp one highlights a broader
(non-showstopper, but worth noting) obstacle, which I alluded to before:
BALE's/CABAL's event dataset was simply not created with iCal in mind.
iCal favours a particular form of data organisation (e.g., the strict
type enforcement on fields of type DATE-TIME) and assumes a particular
degree of brevity, which is why the converted SUMMARY fields aren't
working all that well: They're written with the generous screen space of
a BALE event line in mind, not the small-screen-box space typical in
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.
More information about the conspire