A few thoughts on extending the existent events module. The target is a consistent, modular, and flexible scheduling add-on to drupal. Probably best implemented as a set of modules. The rough specs below are adventurous and probably over the top. I'll try and knock together some demo code, by refactoring the existing event + some additional code as a proof of concept.
- event_or_calendar api
(I'm very bad with naming things, when unclear what should they mean)- collects the calendar data within a specified interval according
to an (optional) taxonomy filter and (optional) owner/responsible/atendee/... - verification of event data
- alerts and notifications (could be extended as an job scheduler - mind the security considerations)
- provides a consistent interface to get/add/modify different calendar data
- a 'calendaring/scheduling' adapter
resposibilities - abstraction, syndication
- collects the calendar data within a specified interval according
- calendar sources
- native - event ans task tables in the local database
- external - remote calendars in ics, rdf, rss, whatever format, cached locally for performance
responsibilities - data storage and retrieval
- calendar module
- displays simple calendar block
- displays a monthly calendar
- displays a yearly calendar
- displays a weekly calendar
- displays a day calendar
- displays a todo list
- displays a todo/schedule calendar( yearly,monthly,weekly,daily)
- displays a free-busy calendar
- implements the node_api to display its pages
- uses the event_or_calendar api to get the data
- themeable
responsibilities - html rendering
- icalendar module
- implements the node_api to render icalendar (rfc 2445 & rfc 2446) feeds
- uses the event_or_ calendar api to get the data
responsibilities - iClendar rendering - to sydicate the calendar into personal productivity tools like Evolution, Outlook, ...
- event
- any node storing information in the event table
- uses the event_or_calendar api to store the 'event' data
responsibilities - store/deliver/render the node specific data of an event
- todo item or task -similar to event with a few (crucial) differences
- has a due date
- the start date usually is the creation date
- has a priority - weights could be used for sorting events, but priority has a stronger meaning
- tasks have ownersip/responsible person
- a task/todo item is a node using the tasks table
responsibilities - store/deliver/render the node specific data of a task or todo item
- "old style" event node a simple node type providing back compatibility with existing event databases
responsibilities - a specific event node
probably it is a good idea to keep calendar,events,tasks in a common api, since all of them are related to scheduling and could be intermixed in different renderings.
Comments
Added to public wiki
Thanks for the link -- I've actually imported this post directly into the public wiki. I added a few brief comments inline -- it might be easier to edit there rather than a long string of inline comments here, but I'll check both places.
Thanks for the wiki
I'll try and keep uptodate. I'll be putting more info into the wiki, as the things go along.
I think what the current ev
I think what the current event module should do is:
Everythign else should be in external modules that use the infrastructure that event.module provides.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
--
Drupal services
My Drupal services
trying to hack a means to granularly subscribe to schedules
I'm trying to put together a means to have users subscribe to other users' schedules. I want it to be usefully both intra and inter sight
would love to have Drupal sites discover other sites scheduling feeds and parse the subjects and more.
Here is an example of the immediate applications. I was kicking around doing a site for my 12 year old daughter. She wants to be able to manage her large course load (it really is incredible how much they put on these kids) and juggle her schedule with the ability for her mother, father, teachers, and Friends to subscribe to relevant items or classes of items. She has several classes of extracurricular activities including athletic, club, friend and family items that are all classifiable. However to be really usfull and potentially majorly usefully (need an adjective not too full of import ) her teachers, coaches would ideally be able to change individual schedules or more like mass change all schedules under which they have authority. For instance her math teacher might change his test date and publish this change which will affect only students that have the classes. The headmaster might change the day of a holiday or something affecting the entire school. A club not affiliated with the school may change or schedule and event which should ideally show up in her event calendar.. Now lets say her grandmother is following her schedule from another country or a parent is following it with an eye toward transportation etc. All of the above changes should be incorporated automatically in her schedule which would then be re-fed to the interested parties who subscribe.
My head began to hurt when I tried to map out all the permutations and relationships. The aim is to have every student in her school have a separate Drupal installation in sub domains with a separate database on the school server (they don't have to be on the school server obviously they can be in random places but this is the concept). The ability to address the scheduling and announcements of all the above an more would be a strong enticement to adopting a single open source application. Actually when I scratched the surface I found alot of real genuine need for this. Its not simple and other have tried and failed at some kind of direct (not service based )updating. Moreover I'm getting convinced that the Drupal style taxonomy is possibly the only way to handle this without creating a separate scheduling only application which would defeat the purpose altogether. Got to go.
It would be better to: prov
It would be better to:
This simply means that an event is anything that has 'event properties' stored in the event table.
I'n not sure about the calendars - yes, calendars do display events. But they could be a much diverse monster, not only display wise. But yes, some default views should probably be provided
The above outlines, are more for a group of modules, rather than a single one. I'm trying to refactor the current event module, but have problems with my code reading skills. I'll try and demo something soon.
No doubt its a magnet for complexity
This one is going to requre alot of thought as you point out. Good luck and let me know if I can help.
my mindmap on the subject
I'm quite busy at work (iproms,4m and a few others), so I haven't done any coding, but just to keep you up-to date with my though train - here is a mind map. It's a sort of an attempt to structure what do I see. I'm concentrating at the moment on the event and the date/length/recurrence model as in the above RFCs.
Unfortunately, too many other ideas are constantly coming, so it's a bit slow, or I need more discipline.
an update to the map
I've exported the above map as well as a summary of ical recursion rules as xhtml from vym. The recursion rules map is based on the rfc, I haven't verified it, so it may be partially incorrect, but reflects the spirit of the specification. The reason for going through the pain of reading specifiactions is that when factoring this functionality for drupal, I want it to be a correct subset of ical, and its rdf equivalent.
i find this really interestin
i find this really interesting!
it also made me think of the phpicalendar project : http://phpicalendar.net
if you could also "squeeze in" some sort of member calendar functionality and a mulitple calendar view based upon each members calendar for it would be perfect.
i know it's a long shot, but have you got any eta. on this project?
:water
No eta for the time being
No, but will try and put an implementation/release schedule. I need it ASAP, this means I'm putting some time into it.
anything I can help with?
I'm seriously considering using Drupal for my organization's site (http://bsp.berkeley.edu), but it partially depends on being able to have each of our (approximately) 1200 students and 10 or so staff members having their own calendar. Thus, I'm very interested in furthering the state of Drupal's calendaring system.
Having personal calendars
Having personal calendars will involve very little coding these days. Maybe none, depending on use case. At the moment you can have calendars filtered by category and content type, when you throw in the permissions system the possibilities are big. If nothing is suitable, you could implement a user filter for the calendar views. But in a lot of cases that wouldn't be nessesary.