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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
