[conspire] July schedule posted

[Rick Moen]

Quoting Tony Godshall (tony at of.net):
> On Mon, Jul 6, 2009 at 7:37 PM, Rick Moen <rick at linuxmafia.com> 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.

Huh?  BALE is not maintained in HTML, and has not been for quite a few
years.  It's a PHP template that draws events data from MySQL rows.  A
Python script, newmonth.py, runs via cronjob on the first of each month
and populates a new month's rows in the "events" table based on
specifications (e.g., 3rd Thursdays) in a table called "eventtemplate".
There's also a third table called "groups" that houses the
basically-static group descriptions that comprise the bottom 2/3 of the
page.

BALE _used_ to be flat HTML.  Then, we templatised and automated it.
These days, I have to use my choice of MySQL tool, if I have to edit
either an event template, or edit an event already generated from a
template or entered by me manually.

Having to chase down events already generated by template is
particularly tedious.  For example, Smaug in Santa Cruz, which meets
every Monday night, has just decided to change locations, which means I
need to chase down and edit three months of events rows for them, in
addition to editing the template to fix future months not yet generated.

Also, BAFUG just changed venues from Yahoo to Juniper Networks, so I
need to do the same drill for them -- but at least they meet only once a
month.


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

The "elsewhere" they were from is yr. humble servant.  From me.  They
are of two types:  1.  Non-templated technical events.  An example is
the Electronics Flea Market in De Anza College Parking Lot A.  Those
cannot be fully reduced to template (well, not within reason) because
they are seasonal (March through October, i.e., the non-rainy season).
Technically, I could create a template for that, but then I'd have to
keep remembering to remove autogenerated enteries during the winter
months.

2.  Holidays.  I manually enter those into the events table, using a
MySQL editing tool, working from my notes in
http://linuxmafia.com/bale/holidays .  There are two reasons I include
them:  a) They are in many cases quite significant for scheduling.
E.g., groups like BayLISA that meet on 3rd Thursdays need to always
remember about the conflict with Thanksgiving Day -- and SVLUG has
occasionally decided to cancel a meeting that's fallen on Independence
Day.  b)  They give a bit of extra interest to the calendar, and help 
prevent us looking like a bunch of ignorant techies.  I figure it won't
hurt people to know when Rosh Ha Shana (the "head of the year) 5770 is, 
nor to mention when it's Eid al Fitr.  Might even inspire a few people
who're unclear on what they are to look them up.

Anyway, even if you can argue that the second type ore somehow not worth 
preserving in the calendar -- and I disagree -- the first are most
definitely not.  And there will always be occasional, significant events
that are day-long or for some other reason have no explicit start and/or
end times.  Software that processes that data needs to deal with them,
not just punt.


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

I'm not sure I understand your "one-time, one-way" reference.  Did you
think I was going to stop using MySQL as my upstream repository of event
information?  No, I really don't think so.

I was not, for example, intending to throw away the BALE page and tell
people "look at PHP iCalendar in the future".  For one thing, PHP
iCalendar may look pretty, but its presentation of data sucks rocks from
a functional perspective.  BALE's one-event-per-line format is finely
tuned to what, in my experience, people really look for.  That's why
it's the way it is.  

Nor was I proposing to convert the BALE page's PHP from back-ending in
MySQL to back-ending in an iCalendar file.  Just no.

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

Of the RFC 2445 iCalendar spec?  Not that I know of.  What I was saying
is, PHP iCalendar gives you RSS for free.

> That makes it more complicated.  I'd say calendars are specialized
> enough you'd want something that can read icalendar/vcalendar instead.

Um, PHP iCalendar _does_ read iCalendar.  Thus the "iCalendar" portion
of its name.