[conspire] July schedule posted
Rick Moen
rick at linuxmafia.com
Mon Jul 13 17:15:47 PDT 2009
Quoting Tony Godshall (tony at of.net):
> Heh. You assumed I knew your architecture. Silly assumption. ;-)
>
> You'd given me only bare outlines. From what you said it could be
> easy or hard to convert.
>
> Now that you've described your existing process more thoroughly I know
> it would be a time-consuming bear.
>
> Or I should say, I trust you that that's true because still haven't
> seen the internals I don't have the PHP.
>
> But you seem reasonably trustworthy. ;-)
Actually, the point was that you _still_ seemed (at least as of your
prior post) to be assuming that I'd be delighted to drop everything and
rearchitect BALE to make it serve up static-page snapshots of the PHP's
output. Whether you've seen the PHP or not is kind of irrelevant to the
point.
(I can create a tarball, but it'd also need some sort of dump of the SQL
schema to be much use to people.)
> > But, anyhow, to implement that idea in the present context, I'd have to
> > rearchitect BALE. I could create a Makefile that somehow runs the PHP
> > interpreter locally on linuxmafia.com, munches an autobale.php file,
> > does necessary MySQL queries and spits out the resulting output to
> > /var/www/bale/index.html, along with presumably a bale.ics file
> > somewhere if/when I cajole PHP into doing that.
>
> Well, how about the python icalendar module i referenced, an example
> of which i hacked up for you already. If you give me a sql dump file,
> I'll even add the parse-the-sql-dump bit I left out and see if it'll
> actually run.
You're welcome to do that, but Deirdre says she has in mind to do the
same sort of thing using Ruby, and we'd just run that from crond,
somehow.
Since I was asked about the schema recently on the SF Perlmongers list,
let me just quote my post:
The raw data are in MySQL tables, queryable only from localhost, and of
course maintained on an ongoing basis by yrs truly. What you're seeing
in the calendar portion of the (PHP) page is rows drawn from table
"events". The group descriptions below the calendar are in table
"groups". Once a month, a cronjob runs that populates a new month of
"events" rows, based on data parsed from table "eventtemplate".
mysql> show tables;
+------------------+
| Tables_in_events |
+------------------+
| events |
| eventtemplate |
| groups |
+------------------+
3 rows in set (0.00 sec)
mysql> show columns from events;
+-------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+-------------+------+-----+---------+----------------+
| eventid | int(11) | NO | PRI | NULL | auto_increment |
| ename | varchar(40) | YES | | NULL | |
| ecity | varchar(40) | YES | | NULL | |
| ecounty | varchar(40) | YES | | NULL | |
| edate | varchar(40) | YES | | NULL | |
| starttime | int(11) | YES | | NULL | |
| endtime | int(11) | YES | | NULL | |
| description | text | YES | | NULL | |
| gcode | varchar(25) | YES | | NULL | |
+-------------+-------------+------+-----+---------+----------------+
9 rows in set (0.01 sec)
mysql> show columns from eventtemplate;
+-------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+-------------+------+-----+---------+-------+
| gcode | varchar(25) | NO | MUL | | |
| weekday | int(11) | YES | | NULL | |
| weekofmonth | int(11) | YES | | NULL | |
| starttime | int(11) | YES | | NULL | |
| endtime | int(11) | YES | | NULL | |
| description | text | YES | | NULL | |
+-------------+-------------+------+-----+---------+-------+
6 rows in set (0.01 sec)
mysql> show columns from groups;
+-------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+-------------+------+-----+---------+-------+
| gname | varchar(40) | YES | | NULL | |
| gcity | varchar(40) | YES | | NULL | |
| gcounty | varchar(40) | YES | | NULL | |
| description | text | YES | | NULL | |
| gcode | varchar(25) | NO | PRI | | |
| active | tinyint(4) | NO | | 1 | |
| outofarea | tinyint(4) | NO | | 0 | |
+-------------+-------------+------+-----+---------+-------+
7 rows in set (0.01 sec)
Here's the most important part of index.php, the bit that does the
calendar section:
// make the dates for the months of the events
for ($i=0; $i< ($nummonths + 1); $i++)
{
$t = mktime(0,0,0,date("m")+$i,1, date("Y"));
$months[$i] = date("M", $t);
$years[$i] = date("Y", $t);
$dates[$i] = date("Y-m-d", $t);
}
// now put in the html for the tables
for ($i=0; $i<$nummonths; $i++)
{
require("monthhead.inc");
$j = $i + 1;
$query = "select edate, starttime, endtime, ecity, ename, ";
$query .= "description from events where edate >= '$dates[$i]'
";
$query .= "and edate <= '$dates[$j]' order by edate, starttime";
$res = mysql_query($query);
while(list($edate, $start, $end, $city, $name, $descrip)=mysql_fetch_row($res))
{
echo "<tr><td";
echo $start == 0 ? "><em>" : " class=\"str\">";
echo dateExpand($edate);
echo $start == 0 ? "</em></td><td" : "</td><td";
if ($start == 0)
{
echo "><center>-</center>";
}
else
{
echo " class=\"str\">";
echo timeExpand($start, true);
echo "-";
echo timeExpand($end, true);
echo "";
}
echo "</td><td>$city</td><td>$descrip</td></tr>\n";
}
echo "</table>\n\n\n";
}
> You point is well taken.
>
> Well, 90% well taken.
>
> 5% doubt: if icalendarphp version that takes *seconds* of CPU time to
> serve up a small plaintext file will certainly cause noticeable load
> if multiple people hit it simulatneously. And you have to admit that
> the BALE is popular.
Neither release of PHP iCalendar is a production portion of my Web site
-- and I hadn't decided for them to be.
Anyway, if I _were_ to do so, it would not be feasible to serve up
static snapshots of it, because of the way that software works, i.e.,
arbitrary views of calendar data according to criteria dynamically
specified by the user.
> But yes, it's good that you got over it once you understood that I
> hadn't understood that you have a large and complex php and mysql
> structure you'd rather not change...
I could swear I said that BALE is PHP-driven immediately. Also, the
subject has come up quite frequently on this mailing list in the past.
Anyway, I've just now replaced the static CABAL page with an index.php
similar to that of BALE, per your upthread suggestion.
More information about the conspire
mailing list