<br><br><div class="gmail_quote">On Tue, Jul 7, 2009 at 12:57 PM, Rick Moen <span dir="ltr"><<a href="mailto:rick@linuxmafia.com">rick@linuxmafia.com</a>></span> wrote:<br><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">Quoting Tony Godshall (<a href="mailto:tony@of.net">tony@of.net</a>):<br>
<br>
</div><div class="im">> Interesting.<br>
><br>
> So you want the calendar generated dynamically?<br>
><br>
> Why?<br>
<br>
</div>Um, no.  I never said anything about wanting any calendar (other than<br>
BALE's) to be generated dynamically.<br>
<br>
We seem to somehow miscommunicating.  I am not 100% sure of what that<br>
miscommunication is, but one guess is that you have conceived the<br>
problem to be addressed in some radically different fashion from the way<br>
I have.<br>
<br>
I understood the problem to be offering iCalendar format, as a<br>
convenience to a rather small group of users, including yourself, who<br>
actually use it and prefer it.<br>
<br>
Therefore, I understood you to be attempting to write Python code able<br>
to grab the event data generated by BALE's output, and/or present on the<br>
CABAL page, parse out the respective page's data, and create a<br>
downloadable iCalendar file based on that data.<br>
<br>
The application "PHP iCalendar" is a Web viewer / display application<br>
able to present one or more iCal data file's contents to the public.<br>
To a limited extent, it is also usable as a data format validator for<br>
iCal files, in the sense that any data file it chokes on almost<br>
certainly has big problems.<br>
<br>
As I suggested in my separate posting, have a good look at the current<br>
almost-complete BALE data displayed from bale.ics on<br>
<a href="http://linuxmafia.com/calendar/" target="_blank">http://linuxmafia.com/calendar/</a> , and then compare that against the full<br>
current dataset's display on <a href="http://linuxamfia.com/bale/" target="_blank">http://linuxamfia.com/bale/</a> .  I hope<br>
you'll agree that PHP iCalendar is prettier but less functional for the<br>
actual needs of technical people wanting to know what's coming up in the<br>
Bay Area.<br>
<br>
I put a copy of the bale.ics within PHP iCalendar's data directory in<br>
order to look it over, and also to test whether it's valid and useful<br>
iCal at all.  (Iniitally, it was not, until I did some repairs to your<br>
script.)<br>
<br>
If, hypothetically, we were to fix the two remaining problems with your<br>
script -- year rollover, and inability to process events without<br>
start/stop times -- then I could create a cronjob to regenerate bale.ics<br>
periodically (wget, then run your script), and create a download link<br>
from the BALE page.  I could optionally also refresh the copy in PHP<br>
iCalendar's data directory, thereby giving folks an alternate view of<br>
that data plus an RSS feed.<br>
<br>
That would be nice.<br>
<div class="im"><br>
<br>
> I would have set up make to build a static html version of the calendar<br>
> anytime its vcalendar source file changed.  That way the webserver is light<br>
> and fast and static.<br>
<br>
</div>A guess:  You seem to be assuming that I am intending to convert<br>
everything over from backending in MySQL (in the case of BALE) and flat<br>
HTML (in the case of the CABAL page).  I never said I'd be doing that,<br>
and I definitely have no such intention.  It would be particularly<br>
stupid to lose MySQL as the back-end to BALE.<br>
<br>
<br>
Before we discuss further, we should make sure we both understand what's<br>
going on and what problem is on the table.<br>
<div class="im"><br>
<br>
> You only need dynamicism if the calendar is read-write, no?  I've certainly<br>
> set up webcalendar's icalendar support for that (with thunderbird +<br>
> lightning- not 100% satisfactory).  But in this instance, you want a<br>
> easy-to-maintain icalendar file that others have RO access to (a simple http<br>
> url) plus an HTML version of same for the web page.<br>
<br>
</div>I'm sorry, but when on earth did I talk about maintaining iCalendar<br>
files?   I'm treating it so far as an export format -- which outcome<br>
your almost-functional script comes rather close to permitting.  Which<br>
would be cool.</blockquote><div><br>Yes, we do seem to be miscommunicating a bit.  <br><br>I did not infer the details of your MySQL template system from what you 
had <br>said so far. But now you've explained it a bit more and I think I see where<br>you are coming from a bit better.<br><br>We did both observe or agree that iCalendar/vCalendar files were easy to edit.  <br>They also have the repetition issues solved.  I stated that the way I would do <br>
things would be to use them as the source.  And to generate the HTML from <br>that.  I did not say you had to do it that way.  Regardless of which direction <br>you choose to go, a tool to build iCalendar from HTML appeared to be a good <br>
first step, so I took a hack at that.  <br><br></div></div>If you want a good generalized to/from iCalendar tool that'll handle a lot<br>of the niceties for you better than your improved version of my hack, <br>perhaps this would be a better tool:<br>
<br><a href="http://pypi.python.org/pypi/icalendar/2.0.1">http://pypi.python.org/pypi/icalendar/2.0.1</a><br><br>Tony<br>