[Design] annotations in Chandler

[Brian Kirsch]

See comments inline

Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
(415) 946-3056
http://www.osafoundation.org



Mimi Yin wrote:

> Good point. For Chandler to be viable as a 1.0 email client, we would  
> need to support versioning some kind of crude versioning so that user- 
> edits never corrupt the "original mail" and users always have access  
> to the original mail.
>
Mimi the original email content is already stored in lob as part of the 
Chandler MailMessage item. So getting access to the original content 
even in Chandler .6 is not an issue :)

> (Could we, for example, store the original mail as an attribute of  
> the content item?

We do already


> subsequent edits may not be versioned, but the  original mail is 
> always maintained in some form, even if just raw  text? it would 
> mostly be hidden from the user unless they did  something explicit to 
> see it...the same way you can tell your client  to expose the raw mail 
> headers to you, but they're hidden out of the  box.)
>
> However prior to being a viable 1.0 email client, I think there is  
> room to study how people mark-up and edit their content while  
> Chandler is more of experimental wrt email..more of a task and  
> calendar app that has email functionality and less of an email client.
>
+1

> Mimi
>
> On Nov 14, 2005, at 6:36 AM, Steven Healey wrote:
>
>>> Mimi
>>> It's really a question of philosophy, I'm proposing that we take the
>>> 2nd approach and let users do what they want with their data, even if
>>> it means corrupting the original content...until we are able to
>>> provide more robust annotation functionality. We can probably learn
>>> a lot about how to do annotations correctly, by studying how
>>> people "annotate" their content on their own.
>>>
>>
>> There was a discussion on this list about 18 months ago concerning  
>> the legal
>> consequences of editing received e-mail.  That might be a good  thing to
>> review at this point.
>>
>> sPh
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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