At the Events 2.0 presentation DWW took notes during the session. Most of the presentation was to provide context for the Revised Event Spec – published here earlier.
Huge shout out to DWW for taking such detailed notes - I've gone through and tried to edit a bit so that people who were not there would have a little more context - DWW - if I've screwed something up please don't hesitate to point it out....
Drivers for Events 2.0 -
There is not a lot of functionality within the Drupal modules around Events.
Some of the modules don't “play well with others” and are not being maintained
Direction Forward:
CCK
Signup
RSVP
SendMail
Workflow
Actions
CCK and the Date module are the basis for “Events”, they provide the basic structure.
We need to realize that “Events” cover a lot of ground -
- personal calendaring/meeting scheduling
- milestones (project end dates, etc)
- ticketing/eCommerce (paid entrance to event, physical ticket)
- parties and small, informal meetings
In addition to the complexity of feature sets we also have to deal with technical implementation issues like “time issues”
all day
recurring
overlap
irregular schedules
We began to talk about “Events” functionality by creating some large buckets in which to view events. Dan is interested in the following:
semi-formal events
- open/closed registration
- email/web as primary interface, but needs to handle off-line stuff
- other possible requirements and ways to look at it, want to include stuff in the model
He is happy to continue building out the “spec” and adding features and functionality that are not in his areas of interest in an effort to create a single repository and knowledge base for the entire community.
There was an open discussion which touched on:
- “Events” as a single time slot (e.g. A particular presentation at a conference)
- “Events” as complex aggregates of the primitves (e.g. An entire conference made up of presentations) - A concept of an event “home page”
- There are many needs of people organizing events
- OG presents a possible direction for organizing people and content around events.
- Events will be just another node type -- can add whatever you want via CCK. “Events” will have a very minimalist set of features/fields.
We talked a bit about big training events, academic conferences
- needs are totally different, and very specific than what Dan was documenting
- 2 options to approach:
-- very small module that can be integrated into larger workflow
-- eCommerce-like package/suite that does everything
- ticketing/paying stuff is the dividing line from informal/formal? (not necessarily)
- events with sub-events
re-designing data model of events module?
- lots of work w/n CCK (KarenS's date field)
- replaces about 80% of the functionality of events.module
concerts, gigs, festivals?
- custom event types for everything?
- or is it all built-in stuff?
- gig listings is a big use of this stuff
-- need to start documenting your needs/requirements
homepage for event:
- goes further, even a small gathering needs lots of posts related to it
- CCK allows flexibility
need CCK nodes as the relationship between users and nodes
- make the relationship between a user and a node itself a node
- node-reference + user-reference fields
- other optional fields depending on sites, events, etc.
events and absence of a calendaring system?
- is events related to calendaring system?
-- calendars = pre-defined blocks of time, structure of time
- event is defined as a time period
- display of time period is a separate issue
-- e.g. views_calendar
- all issues around timezones, DST, etc, --> date primitives
- using the ISO date format standard
During the conversation we noted that it would be a good idea to replace the use of “email” with the more general “communication” which would include SMS, email, RSS, whatever.
Perhaps we should look at leveraging “relationships” within events.
- make it more generic, instead of trying to define an event container type
- show how events relate to each other and leave it like that
- all the possibilities are too complex to try to encapsulate it all into a container
micro-formats
- how to properly export all the CCK fields into an iCal/RSS feed
- calendar aggregator -- can't have all these different fields all the time?
different participant types:
- speakers, organizers, etc
- same emails don't go to all folks
- very complex system + requirements
should it become a full-blown project management system?
- should not go down that road
- need to keep it flexible
- could be leveraged within a PM system
Dan attempted to put his work in the context of the Drupal community
- in drupal community, it's about coding first...
- Dan: this is useful, personally for me -- does it have value for anyone else?
- dww: likes to design before coding
- fenton: more design like this would help get a lot more delivered in the long term
-- visualization of what you're talking about is tremendously helpful
- Dan: problem is people who step into the community and say: you should do this
- dominik: wide needs. good metaphor is flexinode -> CCK. things that are too focused, replacing with more generic, flexible solutions
One of the participants (name??) noted that in their practice they deliver websites to customers and:
- keep re-building similar stuff for different sites
- requirements differ so much, every time, that it's ok to have to re-build
- event == something w/ a date/time
- fundamental problem, makes requirements so difficult ...
-- e.g. training events, w/ training companies
-- variations in super events
-- volume/scale becomes problematic
-- therefore, very difficult to make a generic system
packaging:
- take framework, add customizations
- drive that back into a package that could be shared
- configuring all this stuff w/ CCK @ 1 site -- hard to set it up for N sites
most of the use cases here are the same as for groups:
- each event could correspond to a group
- afterwards, use it as a community you've already created
-- formal or informal/loose
- what's the diff between a group and an event-type?
similar to the idea of an "event workspace"
- integration of OG w/ events
- subsites
- all the relationship/group stuff applies at all levels of the meta-hierarchy
-- subevents or event containers both have communities associated with them
events tagged with taxonomies
- categorization
- perms around categories
Comments
What about starting with an
What about starting with an existing "date object," such as those defined by the iCalendar standard?
That buys you something of a data model that has already been thought out and battle-tested, so to speak, in various calendar systems and applications -- Microsoft Exchange, Oracle Calendar, Google Calendar, Apple iCal, etc. And if you start with iCalendar, that may help you with the design of other elements -- the large-scale "events" or groupings of events -- academic conferences, etc. -- could be "calendars" in the sense that a lot of these applications present multiple calendar layers, and can mix/match them to present them as one huge combined calendar or distinct subsets of events.
I think there's also an opportunity to interop with the CalDAV standard (which defines more than just the publish and subscribe of an entire calendar), as seen in the OSAF projects (Chandler et. al.) and Apple's upcoming open source calendar server. It also looks like Oracle is part of the CalDAV effort, so there could be interop with Oracle Calendar, too.
I'm interested in this because the use of events and calendars is one of the main reasons I've followed Drupal over the years. However, as something of an outsider looking in (i.e. I'm not a developer) it seems like there's been a lot of discussion about events and calendar and perhaps it's just time to adopt some of the successful models that are already out there. Is that out of line?
mind shift
I would like to add two keywords that I noticed were missing in the events discussion:
"Event-Driven Architecture" and "service bus"
These would make events fundamentally more important than they are now BUT will diminish complexity in the long run.
Real life is a group of complex events that are important to an enterprise (or a community, an organisation, a family, an individual, etcetera) that software needs to respond to or work with.
I think I should not explain what others can explain better, so I'll add links and ask the "events-in-drupal" group to take notice:
http://www.gartner.com/DisplayDocument?doc_cd=116129
http://www-128.ibm.com/developerworks/webservices/library/ws-soa-eda-esb...
http://soa-eda.blogspot.com/index.html#115622900797372331
/alldirt
Good Observations
I haven't had a chance to look at the links you provide but both concepts - "Event-Driven Architecture" and "service bus" are very familiar and things that I personally have been aware of and involved with for many years. Given that the details of what you are pointing out and my experience may diverge somewhere I would say that:
Does this address your suggestions?
event vs node
Thanks. I Know, you know a lot more about this subject than I do.
What I think I am trying to do is to provoke a fundamental discussion, if needed. It may be that I don't grasp what's behind the scenes, but it appeared to me that use cases were the main focus of the current discussion. As a reflection I've seen some screenshots of input fields.
The complexity of the "participant interface" and "event organizer interface" seem to imply that we should dig for something more fundamental first, before talking about event functionality.
I mean organising a festival is as much an event as registering a room, having a birthday, passing a point in time, reaching 100.000 drupal users, or whatever you call an important event for your community or website.
I was hoping that the essentials of all events would become the same (if they aren't already). If they are essentially the same, then all events can be addressed in the same way and it will be less hard to implement those complex interfaces you have drawn for all types of events.
It maybe provocative or far fetched but would it be worth considering whether "events" could represent all relevant or important occurences in a community, in the same way that "nodes" represent all content of a community?
An other thing that is suggested in the links I have given, is to publish events in a standard "global data space" (being a standardised infrastructure or service bus) without touching other modules. Modules could interact with the service bus through 'publish and subscribe messaging' (instead of 'request and reply'). Event types can be added or removed without touching the infrastructure (like adding a creditcard type to a payment workflow).
Now, I'm not a specialist neither in architecture nor in drupal, I'm just trying to be a community member. I am suggesting things I have read which seem appropriate to bring to the light.