[Cosmo-dev] This and Future issues

[Bobby Rullo]

Hi all,

Due to the way that we've decided to implement "This and Future"  
changes, there's some tricky issues with these events in the Cosmo UI.

How we Implement This and Future (skip if you already know):
Instead of using something similar to icalendar's THISANDFUTURE  
recurrence range, we instead modify the original item's recurrence  
UNTIL date to be right before where the new changes will be applied,  
and create a brand new event with the changes. So you end up with two  
completely different items with different UIDs, and their own  
recurrence rules.

The first problem, which we have decided to live with (for now) is  
that this requires an extra request to the server - one call to make  
the change to the original item, another call to create the new item.

The next problem has to do with modifications. Let's say you have a  
daily recurring event that starts on 8/1 and you make a modification  
on the 8/5 instance. Then you do a "this and future" at 8/3. What you  
will see on 8/5 is two instances - one for the old item, one for the  
new. The reason for this is two-fold: The first is that the  
modification was not "moved" to the new item ( where "moved" means  
making a new modification with a new UID, and deleting the original),  
and the second is that according to our recurrence UNTIL date  
semantics modifications which occur after the UNTIL date still show  
up in recurrence expansions (Chandler does that too).

This is the reason behind bug 10279 (https:// 
bugzilla.osafoundation.org/show_bug.cgi?id=10279) by the way.

The third and perhaps most insidious problem has to do with another  
one of our favorite topics - "Items in Multiple Collections(tm)". If  
you have an item in multiple collections do a "this and future" save  
on it, the future items will only appear in ONE of the collections.  
The other collection will have a recurring series which just  
mysteriously trails off.

To solve all of this on the client would involve:
	a) making a request to the server for every modification
	b) make a new modification for each one fetched
	c) delete all the old modifications
	d) figure out all the collections that the original item belonged to  
and add the new item to those collections.

Pros:
	Atom API remains "RESTful" and relatively easy to understand
Cons:
	Kind of a lot of work, risky right now, could introduce new bugs.
	Potentially lots of requests by the client
	Not transactional (i.e. one of these many requests fails, you're  
left in a weird state)

To solve this in a server-side way would involve making a new type of  
Atom request which, given the original Item, and a new Item:
	a) Persist the original item, which would have a new UNTIL date
	b) Persist the new Item
	c) Add the new item to all collections the original one was in
	d) Move all modifications of the original Item which are past the  
UNTIL date to the new Item

Pros:
	Since it's all in one request, can be made transactional
	Less client/server chattiness
Cons:	
	Sort of RPC-ish looking, makes REST purists wince
	Kind of a lot of work, risky right now, could introduce new bugs.


My vote is ultimately with the server-side fix, but I'm wary of doing  
too much work on this right now on either side...

Bobby