Hi, Mimi
One random thought: If we are going to require emailed items to be on
the server, then we don't need to send out the eimml at all. In other
words, we could send an attachment that tells chandler how to get to
the item on the server, but we don't need to send a local copy of the
item, and therefore we wouldn't run into the whole email vs shared
item conflict issue.
The downside of requiring the item to be shared means that there are
now two servers we need to converse with before sending email, so
twice the chance of an error. Also, I think the UI needs to reflect
that the item is being "shared", not "emailed" (i.e. so there is no
confusion with what is expected of a "regular email client").
--Grant
On 12 Mar, 2008, at 10:14, Mimi Yin wrote:
Here is what I understand:
1. If we want users to be able to click on something in an email and
subscribe to an item with Chandler Desktop (without going through
the Hub), the best way to do that is to keep the EIMML attachment
around so that Desktop users can click on it (like .ics attachments).
2. It also seems like we *do* want to keep around the ability to
download email directly into Chandler to facilitate item-sharing
scenarios so that Desktop users can receive invitations to subscribe
to items directly in Chandler Desktop.
Both #1 and 2 are nice to haves however, they complete the item-
sharing workflow, but they're not things we have to have in the
short-term.
On the other hand, we already do #s 1 and 2, so there's an argument
to be made that keeping them around isn't a big deal so long as any
bugs they cause are also not a big deal.
My current feeling is that "spurious conflicts" caused by Edit/
Update are not that common and something we can live with. Does
anyone else been experiencing a lot of 'email-related' bogus
conflicts?
That being said, we *still* need to solve this problem where today
users can send out an item via email and then put it on the server
after-the-fact.
- The original item is sent out without a read-write ticket.
- The recipient could then put the item on the server and prevent
the sender of the item from gaining access to that item on the
server, or vice versa.
I think this pretty much means that we need to *always* publish
items to the server when they're emailed. Meaning, item-sharing is
done via the server, not email, but email is used as a way to
address items to specific recipients and transport the item to
recipients' email clients.
Proposed Workflow:
1. Create new message.
2. Hit Send
- Item is automatically published to the server + read-write
ticketed URL
- If user doesn't have sharing account, they are prompted to get
one ;)
NICE-TO-HAVE
- Ability to specify read-write versus read-only in the DV or a pop-
up or something...
3. Recipients receive email + ticketed sharing URL + EIMML
attachment in their email client.
- Casual Collaborators click on ticketed sharing URL to access item
on Hub;
NICE-TO-HAVES
- CC can add item to their account
- Desktop users can click on attachment to automatically subscribe
to item with Desktop, if they are not online when they click on the
attachment, they should still be able to see the item added to the
Desktop client
I know we've gone back and forth on whether to keep the EIMML
attachment + inbound email functionality, but I think I'm finally
getting a better picture of what's required to make the item-sharing
scenarios work smoothly. So in other words, I think we're close!
Still, I'm interested to hear if I'm still making assumptions that
aren't necessarily necessary ;) and/or if anyone else has
alternative workflow ideas that would simplify the way we do item-
sharing without compromising the user experience too much.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
