Re: [PHPiCalendar-DEV] adding interface to upload new calendars - design discussion

[blaine <la...@us...>]

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