[conspire] July schedule posted

[Rick Moen]

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.

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.)

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.

> 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.


> 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.


> 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.]

> 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.

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.

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.


> 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"?  ;->