[conspire] July schedule posted

[Tony Godshall]

>
> ...
>


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


Oh, OK.  So then parsing HTML is not needed.  Very good.


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

Going vcalendar-based would help you there since repetitions can
have expiration dates.  You just replicate the event, change one's
expiration, the other's start, and adjust the new one's details.


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


Ah, didn't catch that.  The first couple I saw were generic things like
4th of July.


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


I think I saw a tool in Linux that has those.  Shouldn't have to do them
manually.

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.


No, I thought we were maintaining in html and we were snarfing html in to
icalendar

Obviously your process is more thought sophisticated.


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


Nah, the way I'd do it is switch the "master" to something easier than
HTML and switch the HTML to generated.  But it turns out you already
have a better master than the HTML, so it makes sense to generate
both the HTML and the iCalendar from the SQL, I guess.


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


OK


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

Of the project spec.


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

Yes, I understand now.  You are testing using iCalendar to give people a
dynamically- generated html of the icalendar stuff.  I'd do it statically
with
make file.  Like you found, iCalendar processing is rather CPU-intensive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20090707/4f578bf3/attachment.html>