[Design] [Please review] Updates to Stamping, aka Edit/Update Spec

Mimi Yin mimi at osafoundation.org
Wed Feb 14 14:35:16 PST 2007


More inline...

On Feb 14, 2007, at 1:45 PM, Grant Baillie wrote:

> Hi, Mimi
>
> I went over the changes you outlined and those make sense.
>
> I've quoted the newly added "Sending, Editing and Updating  
> Recurring Events" section below, and added comments inline.
>
> --Grant
>
>> In the Preview timeframe: Send, Update, Forward and the Addressing  
>> fields will only apply to the entire event series.
>>
>> In order to achieve this simplification, we need to be able to  
>> keep track of edits on a per attribute basis. Grant and Jeffrey  
>> are working through the details of this as I write.
>>
>> This will be new functionality.
>>
>> Currently if I change the Title of a single instance of an event  
>> series, the event becomes 'detached' from the series, which means  
>> that if I then go to edit the Location of that event, I can no  
>> longer apply my change to the entire series.
>>
>> Similarly, if I apply a global edit to the Location field from a  
>> different instance in the event series, that global edit will not  
>> apply to this 'detached' instance.
>
> As of a couple of weeks ago, this feature landed in Chandler trunk.  
> So, I guess all the future tenses need to become past (i.e. move  
> from LATER to DONE :).

Kewl.

>
>> Open issues:
>>
>>    1. When/if we support per instance, per attribute modifications  
>> to recurring events, then we will be able to do things like modify  
>> an attribute on a single instance, while still applying global  
>> edits to the series on all other attributes.
>
> Yes.
>
> Also, the answer to
>
>>    6. If so, can we mark individual instances of a recurring event  
>> or the 'This and Future' subset of a recurring event series as  
>> 'Needs reply'?
>
> is Yes.
>
> As a general comment to 2--5 and 7--8 below, I'm wary of trying to  
> do things like replying to individual instances of events. While  
> the domain model can handle (or be made to handle) this kind of  
> thing, ICalendar isn't very well suited to yanking individual  
> occurrences out of recurring series, so I'm concerned we'll have  
> trouble with non-Chandler clients. In oither words, I think it's a  
> similar situation to allowing individual occurrences within a  
> series be in different collections.

Sure, that's fair. So what's the easiest thing to display in the Body  
of the item? The contents of the Master event?

>
>>    2. How should forward work on recurring events? What do we  
>> display in the Notes field when forwarding a recurring event  
>> series that has modified instances in it?
>>    3. Can we just display the attribute values from the Master event?
>>    4. How should reply work on recurring events?
>>    5. Can we reply to individual instances of a recurring event,  
>> or the 'This and Future' subset of a recurring event series?
>>    7. Replying to an individual instance or the 'This and Future'  
>> subset of a recurring event series would mean the following:
>>    8. Displaying the right thing in the Notes field of Reply message:
>>
>>     * If you are replying to the entire series, display the  
>> metadata from the master event
>>     * If you are replying to a single instance, display the  
>> metadata from that single instance
>>     * If you are replying to the 'This and Future' subset of the  
>> recurring event series, display the metadata from the
>>     * Allowing users to choose between All, Just this event, and  
>> This and Future when marking an item as 'Needs reply'.
>>     * Post-preview, it will mean keeping track of which instances,  
>> or which subset of instances have been 'Replied to'.



More information about the Design mailing list