Sheila Mooney wrote:
I've been wanting to discuss this particular issue for a long time, but have been waiting for the right forum While I think free-busy is an interesting problem, and supporting it would certainly make us look cool, I'm not sure it is as practical or useful as very, very basic invitations... on top of this I'm thinking that very basic, useful invitations would be a lot easier (in terms of hours of labor) than a useful free-busy implementation - we've done most of the work in 0.5 and 0.6 for simple invitations anyway. I haven't seen use cases yet, but say the use case is "A user should be able to set up a meeting with another user in the same work environment" - I see two basic, dogfood workflows: 1) user A talks to user B, user B says "I'm free tomorrow afternoon" - user A makes a meeting on their calendar, invites the user B to it by sending an e-mail with a vcf/whatever attachment (Jeffrey can set me straight here) - user B either accepts it or rejects it. If they accept it, its put on their calendar. (I don't think we'd need to keep track of what invitations were sent/accepted/rejected for a first round - I mean honestly 90% of the meetings you're going to schedule are going to be accepted anyway because our target users are in small workgroups and probably already talk to each other about the meeting in the first place. A rejected meeting could simply generate automated e-mail message that said '[EMAIL PROTECTED] has rejected your meeting "Business Lunch" Please reschedule it.') Requires: (maybe) user A and B talking ahead of time... if they work closely enough together, this might not matter. Technical requirements: A button that says "invite other users" in the detail view. Ability to create an e-mail message, attach an iCalendar file to it, and send it. (we do much of this already) Ability to load a received attachment and insert it into a calendar. 2) user A looks up free/busy information for the other user, and schedules a meeting on a shared calendar. Requires: a shared-calendar relationship that is already established.. either: scenario 1: user A and B share a calendar OR scenario 2: user A has write-access to user B's calendar Technical requirements: Free/busy UI, server support for free/busy queries based on a user, ACL support (scenario 2) I guess I just think that all the parts of the workflow required for a barely usable Free/Busy implementation are fairly complex, require a lot more design and implementation work, and introduce tighter dependencies on Cosmo implementation. If we're trying to minimize the amount of work in 0.7 and still make noticable gains in terms of features, bare-bones invitations seems like the most bang-for-the-buck. [All of that said, if we do end up doing Free/Busy, sign me up, because it sounds like a lot of fun to design and implement.. :)] Alec
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
