|
From: blaine <la...@us...> - 2003-03-27 01:22:34
|
I've actually been thinking about some related ideas for a while now...=20=
I'll just get them out there to [hopefully] provoke some discussion /=20
ideas.
I have two major issues with PHPiCalendar; one of them is actually an=20
issue with Apple's implementation of iCal (or perhaps iSync...)
1) PHP iCalendar doesn't scale well. One calendar works great, 5=20
calendars works ok, and much more than that and it's just unmanageable.=20=
What needs to happen (imho) is for PHPiCalendar to recognise a=20
directory hierarchy filled with iCals as a "calendar store", which=20
could then be navigated.
So, for example, take a directory structure that looks like this:
/webroot (phpical base)
|
+--- calendars
|
+--- film screenings
| |
| +----- theatre 1
| +----- theatre 2
| +----- ...
| +----- theatre n
|
+--- concerts
+--- public lectures
We should then be able to request calendars like so:
http://calendar.mycity.net/concerts/
http://calendar.mycity.net/public_lectures/
http://calendar.mycity.net/film_screenings/theatre_2/
This can / should be done with either mod_rewrite or just setting a=20
phpicalendar page to be a handler for a given domain. (eg: SetHandler /=20=
php-script)
Obviously there are some problems with this;
i) it's not facetted (i.e., if I want to search for theatres by =
type=20
or by city, instead of by name, we run into problems. This can be fixed=20=
either with a handler at the application level (url mapping, through a=20=
config file or database), or at the filesystem level with symlinks).
ii) Multiple calendar support needs to be very carefully thought =
out;=20
such a system could make multiple calendar support extremely powerful,=20=
though --- each user could arrive on-site, and see a customised=20
calendar, or even subscribe to a customised calendar.
iii) descriptions of calendars become useful when you have lots =
of=20
them. Perhaps PHPiCalendar could have an optional SQL backend that=20
stores meta-data that isn't in iCal (or doesn't belong there).
iv) Permissions are a bit sketchy if PHP iCalendar manages 'em.=20=
However, webdav (or ftp, as chad hinted at), already have permissions,=20=
and so they could be used (perhaps as a secondary to $REMOTE_USER).
2) There's no way to have collaborative calendars; you can't publish a=20=
calendar, and then have others directly contribute to it. The only way=20=
I've found around this is to write up a little script that generates=20
iCal files based on input from an online form (which is overly simple=20
and limiting), and having the script mail them to me, so that I can=20
move them to my published calendar. This puts the total load of=20
maintaining a calendar on exactly one person.
Obviously, it would be ideal if Apple would just freakin' support=20
publishing AND subscribing to a single calendar, directly in iCal. They=20=
could even add logic to force a refresh of the calendar before editing=20=
it. But if there were a way to "simulate" this with PHP iCalendar, then=20=
all would be good --- for example, if there were a way to email PHP=20
iCalendar with an event that could be added to the queue, then iCal's=20
"invite" system would automatically enable collaborative calendaring.=20
This sort of thought would require a lot more thought, but could be=20
useful.
Anyways, a lot of this is a long ways off, and perhaps even wishful=20
thinking; if you've made it this far, thanks. :-) Sorry for the rant.
please let me know if you have any ideas; now that the parser is=20
more-or-less done, as I see it steps should be taken to improve=20
scalability, etc. What are others' priorities?
b.
On Wednesday, Mar 26, 2003, at 14:44 America/Vancouver, Mike Traum=20
wrote:
> Hi,
> I'm working on an interface=A0for calendar administration. Here's what =
I=20
> have as a basic design:
> Admin Options
> - Update a calendar (replace a calendar file with a new one)
> - Add a new calendar
> - Delete a calendar
> ...=
|