Skip to content
This repository has been archived by the owner. It is now read-only.

Implement "implicit scheduling", ensure that data for an event is the consistant for all attendees #194

Closed
macosforgebot opened this issue Jan 23, 2008 · 4 comments

Comments

@macosforgebot
Copy link

@macosforgebot macosforgebot commented Jan 23, 2008

@wsanchez originally submitted this as ticket:233


The server needs ensure that the meeting is in a consistant state, so that if the organizer's copy shows cancelled, the attendees' copy is updated. Right now, we rely on the client to request that the server update the attendee's copies.

The CalDAV schedule spec doesn't currently require servers to ensure this happens, but it doesn't seem to forbid it either. Per TC-CalDAV calls, we're considering revising the spec to require this and possibly eliminate the need for the client to even request messaging through the outbox for the REQUEST and REPLY iTIP methods.

It can be up to clients to decide whether cancelled meetings are deleted, in which case, if it is un-cancelled, the server would put a "new" proposal in your inbox for acceptance, etc.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Jan 23, 2008

@wsanchez originally submitted this as comment:1:⁠ticket:233


On concern is how existing clients (eg. iCal) will handle changes in this behavior.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Jan 23, 2008

@wsanchez originally submitted this as comment:2:⁠ticket:233


For example, a PUT of an event on a calendar should immediately schedule a fan-out operation which results in the event being updated for each attendee and an iTIP notice dropped into their inboxes (so that clients know to tell the user of the change). A similar thing should happen when an attendee changes their status.

On our server, there remains some risk here that the data is not consistent if the fan-out processing is interrupted. The server should have some way to persistently indicate that an event needs fan-out and then clear that when the operation is done.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Jan 23, 2008

@wsanchez originally submitted this as comment:3:⁠ticket:233


Initial invite should land in the recipient's inbox, not in a calendar, so that the recipient can still choose to accept it.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Oct 28, 2008

@wsanchez originally submitted this as comment:4:⁠ticket:233

  • Status changed from new to closed
  • Resolution set to Software changed

This is on trunk now

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.