[Chandler-dev] Edit/update (email sharing) model thoughts

[Brian Kirsch]

Hello,
Although I still need to put more thought in to the Edit / Update  
scenarios in Mimi's stamping storyboards, we have
in a Mail Meeting on Monday and via IRC come up with some nice  
starting points.

First I want to frame the context of Edit / Update as P2P sharing of  
item data. Mail protocols (IMAP, SMTP, POP) are simply the
transport used to deliver the EIM information. This is import because  
if we frame our discussions and design in this context
then additional protocols can be leveraged in the future for P2P  
sharing such as XMPP. This would be a big win
for Chandler to have this type of flexibility and gets back to  
Chandler's original intent of being a P2P sharing application.

Having framed the discussion in terms of P2P, I believe the success  
of the Edit / Update workflows depends on the Chandler Mail Service
doing as little work as possible. When receiving mail, it is the Mail  
Service layers role to identify that the mail message contains  
sharing data and
pass that information off to the sharing layer for processing. When  
sending mail, it is the Mail Service's role to identify that this  
outgoing message
should share item data and call out to the sharing layer to serialize  
the data for transport.

Does this strategy sound familiar? Well it is exactly how we send and  
receive Ical .ics attachments in Chandler today.

The Mail Service sees that the message contains an ics attachment and  
calls out to the Calendar / VObject code to de-serialize the
data. The Calendar / VObject code parses the ics attachment and sees  
if the data matches an existing item in the repo. The
Calendar / VObject code either updates an existing item or creates a  
new item based on the info in the ics file.
The Calendar / VObject code then passes the existing or newly created  
item to the Mail Service where the Mail Service applies mail
specific processing such as parsing headers, creating to / from  
EmailAddresses, etc on the item.

In the case of EIM, two items states would be transported the before  
and after. Before is the state of the item before the user made
changes and sent the item via mail protocols. After is the current  
state of the item the user wishes to share via mail protocols.
Presumably, the before and after states can be contained in one EIM /  
XML serialization file.

When sending EIM P2P sharing data if the item is also an event I  
think we would still want to send an ics attachment along with
the message for those people using traditional email clients and  
alternative calendars such as Outlook or ICal.

When a mail is received in Chandler the mail service does the following:
1. If the message contains no ics or EIM xml attachments treat it is  
a traditional mail message and convert the message to an item with a  
MailStamp.
2. If the message contains an ics attachment and no EIM xml  
attachment call out to the Calendar / VObject code and convert the  
message to an item with an EventStamp and MailStamp.
3. If the message contains an EIM xml attachment ignore any ICal  
attachements  and call out to the sharing code to deserialize the item.

In the case of number 3 above the sharing layer would handle any  
conflict resolution including displaying UI to allow the user to  
approve or deny the changes.

There is also a unique case with the Edit / Update workflows where  
the mail service is suppose to send a confirmation email to the  
sender of the Edit / Update.
Although I am not totally convinced at this point that sending the  
confirmation is needed it is part of the stamping storyboard.
This covers the case where the user wants to track his or her changes  
out of band in a traditional email client. What should be contained  
in this email is still up for debate.
  It could either be the full event info including EIM XML  
serialization or just a simple confirmation email ie. You send an  
Update on "%Date" to "%Users".
Either way what should not happen is that the confirmation email gets  
downloaded back in to Chandler and processed as an update for the  
sender.

To prevent this I propose that each Chandler instance should have a  
unique application level UUID. This UUID would be included as the  
mail header X-Chandler-ID.
When a message is received if the sender is the same Chandler (the X- 
Chandler-ID matches) then ignore the message. This works nicely since  
one of the proposals
for Preview is to have an option where Chandler only downloads mail  
from an IMAP or POP server that is sent from another Chandler. For  
this case, we can leverage
  the X-Chandler-ID as the key to determining if the message is from  
Chandler. Thus allowing users to continue working with traditional  
email clients while
leveraging Chandler for intercommunication as is the case with the  
Edit / Update workflows.

Once we have a finalized implementation proposal we can talk about  
division of work. For example, I can help implement the sharing code  
logic
for processing and serializing P2P EIM XML.

Thoughts?

-Brian



On Dec 8, 2006, at 7:27 AM, Grant Baillie wrote:

>
> On 7 Dec, 2006, at 21:47, Jeffrey Harris wrote:
>
>>> That being the case, it would be helpful to know which kind of  
>>> emails
>>> you're talking about here, and throughout your message.  :)  Without
>>> that information, I can't tell what the rest of your post is  
>>> proposing,
>>> or what problem it's intended to solve.
>>>
>>> (I also have trouble wrapping my brain around the idea of a  
>>> "changing"
>>> email, but that may or may not be related. ;) )
>>
>> Changing email is definitely related, and it's certainly confusing  
>> at first.
>
> One way to look at this is to think about how Drafts work in many  
> mail clients. To the end-user, it looks as if they're editing an  
> email, whereas in reality the client is creating a new RFC(2)822  
> message and wiping out the original when the Draft is saved.
>
>> The crux of the communication stamp is that the same item can be  
>> edited
>> and shared throughout a process of sending drafts, normally  
>> sending the
>> item, or sending updates after the item's been normally sent.
>>
>> So when I talked about emails, I was referring to updates (i.e.,  
>> drafts
>> of not-yet-sent items, and updates to previously sent items).
>>
>> Now that I think about it, I'm not actually sure what the payload  
>> of a
>> normal send should be.  Maybe the same as an update?
>
> Well, I think we'd discussed on IRC sending out two EIM blobs in  
> emails (the previous and current versions). Presumably, for a first- 
> time send, the previous version wouldn't be there. But otherwise,  
> yes, pretty much the same.
>
> --Grant
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev