[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