[Pkg-owncloud-commits] [php-sabredav] 113/275: Removed the temporary documentation.

[David Prévot]

This is an automated email from the git hooks/post-receive script.

taffit pushed a commit to branch master
in repository php-sabredav.

commit 8b3e342099c0d4a06696c9468c1c0eb82d252838
Author: Evert Pot <me at evertpot.com>
Date:   Tue Jul 29 15:18:06 2014 -0400

    Removed the temporary documentation.
---
 lib/CalDAV/Schedule/Plugin.php | 67 ------------------------------------------
 1 file changed, 67 deletions(-)

diff --git a/lib/CalDAV/Schedule/Plugin.php b/lib/CalDAV/Schedule/Plugin.php
index af1e3a0..97ac49a 100644
--- a/lib/CalDAV/Schedule/Plugin.php
+++ b/lib/CalDAV/Schedule/Plugin.php
@@ -46,73 +46,6 @@ use
  *
  * iSchedule is something for later.
  *
- *
- * Scheduling object resources
- * ---------------------------
- *
- * We will check for operations on calendar-objects only. That is, VEVENT
- * objects within CalDAV calendars.
- *
- * The scheduling spec calls normal calendar objects "Calendar Object
- * Resource".
- *
- * Some "Calendar Object Resources" are also "Scheduling Object Resources".
- * There's a few things we need to check to make sure that this is the case.
- *
- * Specifically, if an object has an ORGANIZER or an ATTENDEE property and the
- * specified address matches with one of the values for the current users'
- * calendar-user-address-set property, it's a scheduling resource and the
- * special processing kicks in.
- *
- *
- * SCHEDULE-AGENT
- * --------------
- *
- * Every ATTENDEE or ORGANIZER may also have a 'SCHEDULE-AGENT' parameter. The
- * value may be either SERVER or CLIENT. If this is set to CLIENT, the server
- * assumes that the client is responsible for handling the scheduling message.
- *
- * If this parameter is omitted, the default is 'SERVER'. SCHEDULE-AGENT may
- * also be 'NONE', in which case nobody does anything.
- *
- *
- * Organizer
- * ---------
- *
- * If the current user was the organizer of the object, we'll do the following
- * types of operations:
- *
- * 1. Creating a new scheduling resource -> iTIP REQUEST
- * 2. Updating a scheduling resource -> iTIP ADD or REQUEST
- * 3. Deleting a scheduling resource -> iTIP CANCEL
- *
- *
- * Attendee
- * --------
- *
- * An attendee is not allowed to update many items in the event, such as
- * DTSTART, LOCATION or SUMMARY.
- *
- * An Attendee may change the following things though:
- *
- * 1. Their own PARTSTAT -> results in iTIP REPLY
- * 2. TRANSP
- * 3. PERCENT-COMPLETE
- * 4. COMPLETED
- * 5. VALARM
- * 6. CALSCALE (oddly enough)
- * 7. PRODID
- * 8. add EXDATE items, and remove overridden components in recurring events.
- *    This effectively makes the attendee remove itself from one instance of
- *    the recurring event, and should trigger an iTIP REPLY (because they've
- *    declined the instance).
- * 9. CREATED, DTSTAMP, LAST-MODIFIED
- * 10. SCHEDULE-AGENT (but only if it was already set to CLIENT)
- * 11. Add new overridden components for recurring events.
- *
- * If an Attendee DELETEs the object, we will also send an iTIP REPLY
- * (decline).
- *
  * @copyright Copyright (C) 2007-2014 fruux GmbH (https://fruux.com/).
  * @author Evert Pot (http://evertpot.com/)
  * @license http://code.google.com/p/sabredav/wiki/License Modified BSD License

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-owncloud/php-sabredav.git