Events Package Overhauling Plan
This is some speculation on what would make EventsPackage better
Events are a complicated thing. This page is a resource for brainstorming and planning a professional events package for bitweaver. Please feel free to append ideas, resources, or whatever else may make an events package better.
While this page defines the needs or a possible new implementation for an event calendar system, also have a look at CalendarResearch for an evaluation of existing solutions.
People Thinking and Working On This
If you want to join the fun on a very dedicated level so as to see implemention of this through to reality, add your name or handle here with a method of contact.wjames5: wjames5-at-nyc.rr.com
michael dean: mdean@sourceview.com
phoenixandy: andy at andystanford dot me dot uk
Big Issues
- Event Recurrance
See the first comment by James at the bottom of this page - Invitation and Viewing Permissions Management
- Notification Management
Possible Table Changes
EVENTS TABLE
event_idcontent_id
title - Liberty Package
body/data - Liberty Package
description
start_time
end_time
recurance (will take a stringe of days 0-7, weeks, months, years)
location (text)
lat - Geo Package
lng - Geo Package
category - Pigeonholes Package
comments - Liberty Package
invite_guests - T/F
image
url
permissions - Liberty Package
GUESTLIST TABLE
event_idname
email_address
status
NOTE: The above tables include fields which might be covered by other packages and thus not really be in the table. They are noted with their dependent package.
Additional References
- iCalendar
A widely adopted standard
About
Specification - Mozilla Calendar
- Google Calendar Data API
- Drupal Events
Comments
questions
Especially if they repeat, the time will change every day.
recurance is a complicated issue to handle things like:
First and Third Thursday each month
Second Wednesday every other month
See RFC-2445 for one approach: http://tools.ietf.org/html/rfc2445
How will Daylight savings be handled? Example an event scheduled for 11AM localtime each day. If you convert this to UTC when storing, then when daylight svings starts/stops, the localtime corresponding to the UTC time will move and the event will no longer show at 11AM localtime.
Some events will have multiple dates associated with them, perphaps the event times should be in a separate table? Or force user to enter as multiple events?
Re: questions
events linked with rooms
Trigger System
When "X" occurs, do "Y".
X is the trigger, Y is the result of the action.
Examples:
I think this sort of functionality will add a whole new level to bitweaver flexibility, and I'm wondering if in-site actions can be considered "EVENTS," and if basically, the ability to respond to events internally will be included with the proposed package.
Re: Trigger System
Some comments
End time may be easier to manage as duration as it will track start time then.
( I have some fun with my existing room booking system where the duration changes based on the week of the month which currently we just implement as a set of meetings one for each week of the month - what ever you plan someone will break it :) )
We need a location time zone and daylight saving flag - the new PHP5.2 stuff may handle this, but simple time zone has already been flagged as lacking, and we need some means of managing daylight saving within bitweaver.
( Calendar also needs updating with proper daylight saving flag for local time display)
Room booking system is an extension of this, but I KNOW that we need a full planner rather than the calendar display in order to make it work.
Protector is intended to provide proper group management of content. So people in one group can't see content such as an event that is assiged to a group they are not a member of.
Personally I anticipate a number of types of event module rather than trying to shoehorn everything into one. The package structure of bitweaver allows that to happen easily, and events was just a shell to get it started.