[Cosmo-dev] This and Future issues

[Mikeal Rogers]

I imagine this is also the culprit behind https:// 
bugzilla.osafoundation.org/show_bug.cgi?id=8140

-Mikeal

On Aug 6, 2007, at 5:36 PM, Bobby Rullo wrote:

> 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
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev