[Design] [Proposal] Recurring events in Cosmo

[Bobby Rullo]

That's not exactly what's going on. Cosmo is not creating  
"occurrences" when it expands out an event, it is figuring out all  
the dates on which an event happens so it can index them, which  
allows Cosmo to quickly say if an event happens in a particular date  
range.  So the proposal doesn't quite make sense.

Also, this is an issue that affects Chandler just as much as it does  
Scooby - if you are using Chandler to sync to Cosmo and you have  
recurring event without and end date, it can take a really really  
long time to sync.

The proposal would just be useful as a really temporary measure to  
prevent long syncs (or long saves in the Scooby case)

Seeing as it affects usability in an adverse way and that the Cosmo  
team is working on a longer term solution, I think we should not do  
anything right now in the clients (Chandler and Scooby)



On Apr 19, 2006, at 8:32 AM, Mimi Yin wrote:

> Can we hide the end-date and behind the scenes generate more  
> occurrences on the fly *if and when* the user browses ahead in the  
> calendar?
>
> Perhaps we don't need to worry about editing the end-date for the  
> TargetUser Release, since we're not supporting full editing anyway?
>
> But I agree with Priss that a 1 year end-date would be worrisome to  
> users...and wouldn't make much sense for annual events either.
>
> Mimi
>
> On Apr 18, 2006, at 2:53 PM, Priscilla Chung wrote:
>
>> Yes I understood about the temporary work around. I agree setting  
>> a default end date should be ok for 0.2. Just to be clear, this  
>> restriction should not be in place for the target user release.
>>> * In Chandler and/or Scooby, just make the "recurrence end date"  
>>> UI element default to one year in the future. If the user wants  
>>> to change it, they can.
>> What happens when a user deletes the end date? Would the user not  
>> be able to submit the event? Personally one should be able to  
>> delete the end date as certain events just don't have end dates,  
>> ie. birthdays.
>>> No hidden anything, no changes to Cosmo, just a temporary  
>>> workaround until the Cosmo issue is sorted, which it might be  
>>> soon anyway.
>> To BCM's point, the best thing may be to do nothing in code, until  
>> the bug is investigated. In the meantime we document the bug and  
>> and document the work around, ie. to add an end date to recurring  
>> events.
>>
>> -Priscilla
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design