[dev] Reservations using kronolith

[Jeff Warnica]

Ill second the disclaimer that Im not a kronolith developer...

On Wed, 2004-06-10 at 10:18 -0700, Jason Rust wrote:
> 1. When a user goes to create a reservation they invite, as one of the 
> participants, the resource they want.  Some sort of cron script is running on 
> the server and intercepts the iCal invitation.  If the requested resource is 
> free it sends an acceptance reply to the user.  Downside with this approach 
> is that a cron script is a bit kludgy and it is not the most intuitive method 
> to an end-user.

Rather then a cron script that would check a mailbox, have an alias that
pipes it to a script. Same idea as whups. Some way to control this agent
would be necessary; who can book it, who can cancel bookings, etc. And a
mechanism to actually do the canceling. 

> 2. Create a shared calendar for each resource (this would likely have to be 
> done for idea #1 as well).  The user then selects the resource from the list 
> of calendars when they go to make a reservation.  The shared calendar is set 
> up to not allow overlapping entries in one of the three ways:
> 	a. There is a global kronolith pref that turns off the ability to have 
> "double bookings" in calendars.  Easy to implement, not very flexible.
> 	b. There is a per-calendar pref that turns off double-bookings.  Not much 
> harder to implement, a bit more flexible.
> 	c. A new permission is given to calendars that controls who can double-book.  
> This is the most flexible, but I'm not sure if the perms app is flexible 
> enough to add in a new permission type.
> 
> Which (if any) of these sound like the preferred solution to the kronolith 
> developers?

I think some kind of "agent" would require the least impact on existing
code, and could be more-or-less developed separately from kronolith
proper.