<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">...</div></blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>... BALE is not maintained in HTML, and has not been for quite a few<br>
years.  It's a PHP template that draws events data from MySQL rows.  A<br>
Python script, newmonth.py, runs via cronjob on the first of each month<br>
and populates a new month's rows in the "events" table based on<br>
specifications (e.g., 3rd Thursdays) in a table called "eventtemplate".<br>
There's also a third table called "groups" that houses the<br>
basically-static group descriptions that comprise the bottom 2/3 of the<br>
page.</blockquote><div><br>Oh, OK.  So then parsing HTML is not needed.  Very good.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
BALE _used_ to be flat HTML.  Then, we templatised and automated it.<br>
These days, I have to use my choice of MySQL tool, if I have to edit<br>
either an event template, or edit an event already generated from a<br>
template or entered by me manually.<br>
<br>
Having to chase down events already generated by template is<br>
particularly tedious.  For example, Smaug in Santa Cruz, which meets<br>
every Monday night, has just decided to change locations, which means I<br>
need to chase down and edit three months of events rows for them, in<br>
addition to editing the template to fix future months not yet generated.<br>
</blockquote><div><br>Going vcalendar-based would help you there since repetitions can <br>have expiration dates.  You just replicate the event, change one's <br>expiration, the other's start, and adjust the new one's details.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">> Yeah, those events looked like they were coming from elsewhere anyway<br>

> (canned calendars from ??) so it didn't make much sense to try to deal<br>
> with them in the time alloted<br>
<br>
</div>The "elsewhere" they were from is yr. humble servant.  From me.  They<br>
are of two types:  1.  Non-templated technical events.  An example is<br>
the Electronics Flea Market in De Anza College Parking Lot A.  Those<br>
cannot be fully reduced to template (well, not within reason) because<br>
they are seasonal (March through October, i.e., the non-rainy season).<br>
Technically, I could create a template for that, but then I'd have to<br>
keep remembering to remove autogenerated enteries during the winter<br>
months.</blockquote><div><br>Ah, didn't catch that.  The first couple I saw were generic things like<br>4th of July.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

2.  Holidays.  I manually enter those into the events table, using a<br>
MySQL editing tool, working from my notes in<br>
<a href="http://linuxmafia.com/bale/holidays" target="_blank">http://linuxmafia.com/bale/holidays</a> .  There are two reasons I include<br>
them:  a) They are in many cases quite significant for scheduling.<br>
E.g., groups like BayLISA that meet on 3rd Thursdays need to always<br>
remember about the conflict with Thanksgiving Day -- and SVLUG has<br>
occasionally decided to cancel a meeting that's fallen on Independence<br>
Day.  b)  They give a bit of extra interest to the calendar, and help<br>
prevent us looking like a bunch of ignorant techies.  I figure it won't<br>
hurt people to know when Rosh Ha Shana (the "head of the year) 5770 is,<br>
nor to mention when it's Eid al Fitr.  Might even inspire a few people<br>
who're unclear on what they are to look them up.</blockquote><div><br>I think I saw a tool in Linux that has those.  Shouldn't have to do them manually.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Anyway, even if you can argue that the second type ore somehow not worth<br>
preserving in the calendar -- and I disagree -- the first are most<br>
definitely not.  And there will always be occasional, significant events<br>
that are day-long or for some other reason have no explicit start and/or<br>
end times.  Software that processes that data needs to deal with them,<br>
not just punt.<br>
<div class="im"></div></blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<br>
> > Tony's script went for the low-hanging fruit by saying "just assume<br>
> > 2009, for now" -- which is great for prototyping, but needs to be fixed<br>
> > for production.  I have no idea how, offhand.<br>
><br>
> Yeah, well, again I intended it as a one-time one-way hack.<br>
<br>
</div>I'm not sure I understand your "one-time, one-way" reference.  Did you<br>
think I was going to stop using MySQL as my upstream repository of event<br>
information?  No, I really don't think so.</blockquote><div><br>No, I thought we were maintaining in html and we were snarfing html in to icalendar<br><br>Obviously your process is more thought sophisticated.<br> <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I was not, for example, intending to throw away the BALE page and tell<br>
people "look at PHP iCalendar in the future".  For one thing, PHP<br>
iCalendar may look pretty, but its presentation of data sucks rocks from<br>
a functional perspective.  BALE's one-event-per-line format is finely<br>
tuned to what, in my experience, people really look for.  That's why<br>
it's the way it is.</blockquote><div><br>Nah, the way I'd do it is switch the "master" to something easier than<br>HTML and switch the HTML to generated.  But it turns out you already<br>have a better master than the HTML, so it makes sense to generate<br>
both the HTML and the iCalendar from the SQL, I guess.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Nor was I proposing to convert the BALE page's PHP from back-ending in<br>
MySQL to back-ending in an iCalendar file.  Just no.</blockquote><div><br>OK<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> > On the bright side, PHP iCalendar solves a bunch of other problems.<br>
> > My installed version, 0.9.4 beta, is ancient.  The current 2.31 release<br>
> > (notably) supports the user's choice of RSS version 0.91, 1.0, and 2.0,<br>
> > neatly sidesteps that religious issue.<br>
><br>
> Ah, RSS is part of the spec?<br>

</div><br>Of the RFC 2445 iCalendar spec?  Not that I know of.  What I was saying<br>
is, PHP iCalendar gives you RSS for free.<br>
<div class="im"></div></blockquote><div><br>Of the project spec.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
> That makes it more complicated.  I'd say calendars are specialized<br>
> enough you'd want something that can read icalendar/vcalendar instead.<br>
<br>
</div>Um, PHP iCalendar _does_ read iCalendar.  Thus the "iCalendar" portion<br>
of its name.<br>
</blockquote><div><br>Yes, I understand now.  You are testing using iCalendar to give people a <br>dynamically- generated html of the icalendar stuff.  I'd do it statically with <br>make file.  Like you found, iCalendar processing is rather CPU-intensive.  <br>
<br><br></div></div>