[Design] [D/F] Other's alarms

[Mimi Yin]

I think we also need to evaluate how likely it is that users will  
share alarms with other users without a very specific reason.

e.g. Individual sharing a household task list with their spouse and  
they want to share Custom alarm dates (aka Ticklers).

I believe John had some use cases for wanting to share alarms as well.

What we're really talking about is whether we need to provide sharees  
with an 'out'  when sharers 'do the wrong thing', as in, share their  
alarms willy-nilly, thereby irritating sharees.

Mimi



On Jan 11, 2007, at 2:57 PM, Morgen Sagen wrote:

>
> On Jan 11, 2007, at 2:24 PM, Jeffrey Harris wrote:
>
>> Hi Folks,
>>
>>> In my opinion, I almost NEVER would want alarms from other's  
>>> calendars.
>>> If I want an alarm for an event, I probably would duplicate that  
>>> event
>>> on one of my own calendars. I wish there would be a preference  
>>> not to
>>> import the alarms when subscribing even if the publisher made the  
>>> alarms
>>> available.
>>
>> This does seem like a useful feature.  The UI side of this is pretty
>> trivial (although it'll clutter subscription workflows).   
>> Unfortunately,
>> the data side is a wee bit tricky (at least for read-write shares)  
>> since
>> we need to preserve the alarms when we edit the events.
>>
>> I think getting this to work and testing it is probably a day or  
>> two of
>> work, I'm not sure we can fit that work in before preview, but it
>> certainly seems worthy of prioritizing.
>>
>> Sincerely,
>> Jeffrey
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> When we finish the new sharing work, each individual will be able  
> to choose whether they want to share alarms.  Just because the  
> publisher chose to share them, won't mean you have to accept them  
> -- you'll be able to set your own alarms that are independent of  
> what's on the server.  This is because very soon we will be sending  
> "diffs" back and forth to Cosmo, and the client will be able to  
> ignore any values it's not interested in.  I don't know if such a  
> feature will be supported in the case where Chandler shares with a  
> vanilla CalDAV server.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design