Hi Folks, Here are lots of thoughts about invitations.
** Interop ** One overarching question I have is how committed we are to doing interoperable invitations in 0.7 and beyond. It's not clear to me how well Outlook and Lotus Notes implement iTIP, the IETF standard for invitations (you'll also hear me mention iMIP, iTIP over email). My sense is Microsoft does it badly, Lotus does it well. If we're aiming for interop, everything's a little harder in the short term, but in the long run it's probably easier because the standards are already written, and of course we get a bigger payoff if we can interoperate. Basically, I think we should strive to comply with iTIP. ** Centralization ** iTIP provides for one centralized organizer for a meeting. Other meeting participants can send on behalf of the organizer (in a friendly, the organizer's sick, way), but the organizer's inbox can become a bottleneck if they're offline. Does Chandler want to copy this model for invitations? Or do we want to provide for workflows where participants negotiate amongst themselves without requiring central organizer interaction? ** CalDAV and iTIP ** Unfortunately, CalDAV sharing and iTIP interactions confuse the heck out of me. A small taste: - If I subscribe to an event you're organizing and put it on my calendar, does that mean I've added myself as a meeting attendee? - What if you invite me (via iMIP, the email transport for iTIP messages) to a meeting you're sharing with me? How does my acceptance or lack thereof interact with sharing? - What if you invite me to a few instances of a recurring meeting, but not the whole thing, and I'm subscribed to the whole recurring meeting? I don't want to get too deep into it here, but perhaps standards-oriented folks could meet some time and brainstorm issues we'd like to get clear on. For this thread, suffice it to say that smoothing out the bumps in iTIP and CalDAV seems thorny to me, but still worth doing. SWAG to get a very buggy, probably makes sharing unhappy but works for common cases iMIP implementation with no UI: 5 days ** iMIP Security ** Do we want to try to detect spoofing in iMIP traffic? I think the answer is probably no, at least for 0.7, that would be a royal pain in the ass, but I want to raise the issue. Anyone can spoof an email scheduling, accepting, or cancelling a meeting. This won't matter if your calendar is private (script kiddies won't know what event UID to use), but for public calendars, this could be a pain. ** Free/busy publishing ** There are three major ways of interacting with free/busy I'm aware of. A) Shaniqua publishes her free busy to an HTTP server (could be CalDAV, could be something else) B) Landis publishes all his events to a CalDAV server, the CalDAV server dynamically calculates free/busy C) Delin responds to an iTIP request for free/busy information It would be very appealing to implement B) in a Scooby/Chandler/Cosmo world where users might not be using Chandler all the time. Unfortunately, this requires that users publish their whole calendars to a CalDAV server. This is likely to be significantly slower than publishing a single VFREEBUSY file, so I don't know that we should force people to do this. I also don't know if/when Cosmo is likely to support this. I think we definitely want to support A) and C), SWAG: 5 days. ** UI ** I think a good workflow and UI for creating, reviewing, and accepting invititations is non-trivial, but we can hack together something ugly but usable pretty easily, I expect. I'm a fan of associating free/busy with contacts, not treating it like a sidebar collection, but this requires more contact workflow clarity. So the proposal of treating free/busy just like subscribing to a collection seems fine as a first pass. SWAG for a wildly ugly first-pass invitation UI implementation: 5 days. ** Meeting negotiation thread UI ** I think it would be really cool to render a conversation around an event in some clever way. I don't know exactly how this would look, hence how much effort it would take, but I think it's such a good idea we shouldn't forget about it. :) ** Stamping and Invitations ** Mimi mentioned the idea of unstamping event-ness to reject a meeting invitation. I think this won't play well with sharing. It's very possible that you might invite me to a meeting I already have in my repository because I'm subscribed to your calendar, unstamping the item for you would be bad. If I stamp-as-email, address, then send to invite people to an event, how does inviting more people later work? I edit the existing email and hit send again? That's really different than what I'm used to, but I guess that could work. I suppose uninviting people could work the same way... ** Probably out-of-scope for 0.7 ** (but I'll mention them briefly, anyway) - Delegation (Esther organizes and/or schedules a meeting for Mitch). This is part of iTIP, SWAG: 5 days - Countering a meeting invitation with an alternate time (and accepting or declining counters). Part of iTIP. The message body for this is easy, getting the UI right might be hard. SWAG: 10 days - Cancelling meetings. Again, part of iTIP, easy, good UI isn't necessary, although of course it would be nice to highlight cancellations somehow, which might take more effort. SWAG: 1 day - Jabber transport for invitations (I really want to play with this, maybe in my self-directed time), SWAG: Large - "home time" free/busy vs. "work time". For instance, if I go on vacation for a week, I want family and friends to see a different free/busy than coworkers. I think figuring out how to do this would probably be hard. If you've gotten this far, that means you actually read the whole message. Congratulations, and thanks. :) Have a nice night, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design