Hi Mimi, thanks much for your detailed note. All sounds terrificly useful as described, both for preview and beyond. And if I had finished the chapter of Scott's book I was on prior to sending my message, I would have known that these features/functions have been already thoroughly white-boarded and sticky-bucketed. :) Thanks, Andre
On Thu, 8 Feb 2007 12:04:15 -0800, "Mimi Yin" <[EMAIL PROTECTED]> said: > Hi Andre, > > We currently allow users to detach Event status, Alarms and Triage > status from the share. Post-Preview, we plan on implementing the > ability to Label items (or Tag items) with your own Keywords and > eventually user-defined attributes. I think when we get to that > point, we will want to support what you're describing...user-defined > sharing clouds or at the very least, provide a private annotations > field. For now, I'm not sure how common it will be for people to not > share attributes as basic as Title or Notes. > > Actually, how much work would it be to add a private annotations > field? Would that be a good one to add to the 'Bite-size projects to > help us with' list? > > Mimi > > On Feb 8, 2007, at 11:44 AM, Andre Mueninghoff wrote: > > > Morgen's explanation was my understanding also, that the last > > update in > > time order wins. > > > > On a related note and likely a conversation for another day, it occurs > > to me that it might be useful to be able to "disconnect" an attribute > > from updates by other people via sync. For example, for a particular > > item, I want the title to have some additional keywords or something > > meaningful to only me, so I want to be able to receive updates to all > > other attributes for this item from the people with whom I am sharing > > this item, except for the title. > > > > Andre > > > > On Thu, 8 Feb 2007 10:09:37 -0800, "Morgen Sagen" > > <[EMAIL PROTECTED]> said: > >> > >> On Feb 8, 2007, at 9:58 AM, Mimi Yin wrote: > >>> > >>> 3. However, Chandler users wouldn't have their local changes > >>> automatically overwritten by Cosmo Casual Collaborators. Instead, > >>> Cosmo changes would get stored as Pending Changes and the Chandler > >>> user would decide whether or not to apply them. > >> > >> This is not the case. If the Chandler user changes the title of an > >> event and syncs, and then the Cosmo UI user happens to also change > >> the title of that same event, the next time Chandler syncs it will > >> get the whatever title the Cosmo user set. The Cosmo-side change > >> will not be considered a pending conflict by Chandler because > >> Chandler had already sent its local changes during the first sync. > >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > >> > >> Open Source Applications Foundation "Design" mailing list > >> http://lists.osafoundation.org/mailman/listinfo/design > > -- > > Andre Mueninghoff > > [EMAIL PROTECTED] > > > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > > > 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 -- Andre Mueninghoff [EMAIL PROTECTED] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
