[conspire] July schedule posted

Tony Godshall tony at of.net
Wed Jul 1 18:41:23 PDT 2009

On Wed, Jul 1, 2009 at 6:15 PM, Rick Moen<rick at linuxmafia.com> wrote:
> Quoting Tony Godshall (tony at of.net):
>> A simple "no" would have sufficed.
> Well, actually, I'd far rather say yes.  I'm just unclear on how to
> say yes without quite a lot of work, and also making a simple page
> rather complex (and maybe error-prone and less fault-tolerant).
> Frankly, I'd love to say yes.  It's frustrating that the handful of
> people who keep saying "Please add iCal" and "Please add RSS" seem to
> assume it's really easy, but don't get around to telling me how.  The
> cynic in my head keeps whispering the uncharitable conclusion that they
> have no idea how, but don't care because they aren't going to do the
> work.  That's unfair, so I try not to listen to the cynic.

Sorry, I should have done a quick search before my comment.

I don't read all the messages on this list- just the ones whose
subject lines catch my eye.

> Moreover, it's not like I'm unwilling to do it myself.  I am.  I just
> want to make a good estimate of what I'm getting into, and ensure that
> it doesn't make the page brittle or a pain to edit.  Also, of necessity,
> it'd need to be according to _my_ priority list.  As I commented when
> Grant seemingly tried to get me to commit to an "installfest in a box"
> project, "I just don't bloody well want to commit in public to another
> damned project."
> In case it was not obvious, (1) my spare time is not in bounteous
> oversupply, and (2) for that reason among others, I attempt to optimise
> my Web pages for ease of maintenance and fault tolerance.  (Requests
> that might endanger either of those virtues get more-skeptical looks.)

Of course.

> But, as I said, I'm certainly didn't refuse to do the work -- which is
> why I spent half an hour this morning prototying (upthread) how one of
> the existing CABAL calendar entries might need to get recoded as
> hCalendar data, and then what sort of software setup might suffice to
> then transform it into iCal.

Personally, I'd go the other way.  Edit the calendar in the
easiest (easiest to edit, easiest to parse) format you have
have a couple of scripts spit out the more verbose versions
(html, hCalendar) and cat thenon-generated html to them
to make the html people see.  A perfect application for make.

>> I keep missing things because I don't go to each website.
>> .ics files let me collect them into a single calendar.
> Again, to quote Richard Couture:  "I'm sorry to hear about _your_
> problem."  My willingness to bend over backwards to accomodate people
> for whom the existing calendars -- CABAL's and BALE -- don't meet their
> needs has inherent limits.
> I think iCal and RSS are objectively a good idea for that data, mind
> you -- even though my best information suggests that only a tiny number
> of the data's target audience would currently benefit.  The question
> actually is, how to implement it at all, and how to do so in such a
> way that the effort is not either an initial or an ongoing time-sink.

I'll help you with the initial and  if that's done right, the ongoing should
be a matter of running make after you edit.  (Or from cron, even)

>> But I didn't know until your response whether or not the work had
>> already been done.
> Oddly, the subject has come up, right _here_, with the same answers, a
> number of times (three to five, I'd guess) -- usually with my making a
> point of putting my response in a public mailing list posting rather
> than just as a private mail reply, in a forlorn attempt at public
> knowledge so that I wouldn't have to keep giving the same reply to
> multiple people's private queries.

Sorry, I should have done a quick search before my comment.

I don't read all the messages on this list- just the ones whose
subject lines catch my eye.

>> Anyhow, I think .ical calendars are just plaintext vcalendar
>> entries like Thunderbird/Lightning/Sunbird/Evolution do...
> I'm very familiar with the standard, Tony.  I was writing about it, and
> singing its praises, long before it became popular.
> [Snip your example of an iCal object.]

Sorry I misinterpreted

>> Just as easy to edit in vi as html is.
> And you don't even have to do those damned angle brackets.  However, I
> think you're missing the point:  I _also_ need the HTML, for the 99% of
> users of my Web pages who get their calendar information there and don't
> turn up their noses at data not in RFC 2445 format.

ok, when I do the html-vcalendar transformation bit I'll do the
inverse as well.  then you can do a make that cats it with the
static bits of html to generate the target html as indicated above.

> I hope you weren't saying "Rick, as long as you're already copying,
> pasting, and updating 1994-era HTML table entries for CABAL's calendar
> in vi, please go ahead and use vi to create and maintain a parallel
> instantiation of that same data in iCalendar format, too."  Because,
> that would be kinda cheeky and rude.

indeed I was not

> What would be ideal would be to maintain CABAL's calendar/event data in
> vi once (i.e., in a single location), and have that data parsed out to
> both the current HTML table data (or some successor thereof) _and_ iCal
> data.  Don's suggestion of maintaining the data as hCalendar markup,
> and then generating the iCalendar version using a separate XSLT
> transform, is at least feasible -- albeit the hCalendar CSS markup adds
> a fugly and baroque mess to my HTML.
> By contrast, "just maintain the same data in two places" is a bit
> unattractive.

I'd treat the icalendar/vcalendar as the master and generate the
hcalendar and html since ics is easiest to edit and parse.

Deja vu.  Sorry.  I err too much on the side of overcommunicating
because so many times people don't hear what I actually said.  Oops.
Sharing my problems again.

>> When I have a little time I'll wget your html and run it through
>> a little magic python or perl and give you the code.
> That might work well, and the effort would be appreciated.
> Are you sure you really prefer "no"?  ;->

no, this is better.  we'll get it done.  in a month or two ;-)

I have to go back to actually paying work, but I did get this far...

wget -O- http://linuxmafia.com/bale/ |perl -ne
"date:$1 times:$2 city:$3 rest:$4\n";}'

I figured since cabal calendar is a subset of bale, might as well do
bale and we can just filter for cabal


More information about the conspire mailing list