What Would Your Dream Calendar Program Look Like?

srl sends in this query: "I'm on a project team for Reefknot, which is building an open-source/free shared calendar server. This is not a replacement for Evolution; this is a server that any iCal-capable client can talk to, to do group scheduling and event planning. It may also include project-management features. In short, we want people to have a free alternative to MS Exchange's calendaring features. We are in the pre-alpha design stages, and we want input from end users of calendar software. This might be you, it's definitely your boss. So, we want to know: What does your enterprise calendaring software do that you like? What do you hate about it? Why? What features should we implement to be competitive with existing commercial software?" We've recently talked about Exchange, and calendaring functionality is one of the reasons that it keeps finding its way into the enterprise. If you've ever wanted an alternative, now is your chance to speak up.

Comments

My Wishlist:

[crucini]

I'll avoid the obvious, since you already know what a good calendaring app does (I hope.)

1. Synchronous, "real-time" architecture based on either TCP connections always open from client to server, or UDP packets to update status. What I see on my workstation should never be out of sync with the 'real calendar'. Microsoft's message-based architecture is the wrong way.
2. Windows client that supports both synchronous on-line operation and disconnected operation (for notebooks). Of course if you make an appointment while disconnected, it stays 'tentative' until you sync, and may get rejected then. I don't like Windows or notebooks, but the reality is that the heaviest calendaring users use both. It would be nice to have a similarly featureful Unix client, but realistically most technical people don't like or use calendaring much, while calendaring is the lifeblood of suit/PHB types. The app lives or dies by how well it works for the suits.
3. Outlook compatibility. For now. Ultimately I assume Microsoft will twist Outlook's protocols to make this impossible.
4. Scalability without server sync issues. The existing calendaring apps seem to create 'separate universes' ala Everquest for people on different servers. Therefore you might think you've scheduled a scarce resource, and then find out later when the servers sync up that it was already taken. I think the preferrable architecture is one big database server with a ring of application servers around it.
5. Open API for non-trusted users. There should be a way for people other than the calendar admins to easily script reports, etc. without compromising security. It could just be a simple web interface that doesn't change much. This could also be used to write better clients. It goes without saying that you'd provide an open API for the admins to script to.
6. Fast response. Sounds obvious, but some calendaring apps are sluggish at enterprise sizes.
7. Transactional integrity - two users should never see contradictory information, such as two people thinking they've booked the same room. The only ambiguity allowed is on disconnected laptops, where the ambiguous status is clearly shown to the user.
8. Web access. I guess that's obvious, but please don't use Java or JavaScript or unnecessary graphics. Concentrate on speed, simplicity, and clarity.
9. Again, scalability. It's really easy to make a calendaring system that works on the small scale and can't scale. Once you're supporting far more users than can connect to one machine, you start wishing you had a good architecture. Maybe you should develop the app on a cluster of 486's to force scalability from the beginning.
   1. That's about it. There are lots of bells and whistles I could ask for, but all of them can be added if the API is open. Good luck!

My Dream Specs

[LHOOQtius_ov_Borg]

...in random order, really...

Accepts Outlook 2000 as a client on Windows

Provides an open-source O2k-like client for Linux and Solaris, giving integrated mail, contact management, and calendar a'la O2k

Also allows Web interfacing (over SHTTP), providing calendar, contact, and mail management via an HTML interface

Provides user and group calendars, multiple group membership for users, and administration ability assignable to users, groups, and all (so that assistants and secretaries can manage calendars for their employers and their groups)

Allows selection of which calendars to view, so that the user can see only their individual calendar, or their individual calendar and that of one or more groups they belong to

Automatic creation of group calendar entries based on project plans from M$ project and a similar program on Linux and Solaris (previously existing, or created by the project)
Tags deadlines as "modified" but doesn't delete them when changed using the project mgt software (can select to view modified only, or modified and previous dates in the calendar view)

Allow calendar entries to have dependencies (entered via Project-like software, but also in the calendaring system by clicking on another entry), and the ability to tag each calendar entry as success (in which case dependent entries remain the same) or push them back (in which case dependent entries all move back by same # of days)

Alert users and admins of conflicts between ALL calendars (group and individual) a user is subscribed to, when scheduling new events

Automatic notification of events when they are scheduled, and selectable reminder e-mail params (periodic or one time)

Periodic events

E-mail calendar notifications a'la O2k
Integration of contacts and calendar a'la O2k
Notification of accept / decline of attendees by e-mail a'la O2k; allow attendees to suggest alternate times and meeting scheduler to accept an alternate time and send a new meeting notice

Though client is integrated, back-end system should allow for separate mail and calendar servers (contacts could be stored in the calendar server, or, also separately ... using LDAP)

I can think of more... I'd be happy to join this project as a system architect if the URL were actually working...