(It'd be great to hear from Server folks as well, as this gets into
Item-Sharing in general.)
Okay, let's step a moment and think about what the IDEAL workflow
would be for item sharing. I *don't* think it requires shipping items
around in email messages, so I'm of the mind that stripping the EIMML
attachments from email messages is the right thing to do, both for
the short-term and the long-term.
What I'm not sure about what kind of support we want to provide for
'downloading' email into Chandler.
I understand that we will probably not get to this full-scale
scenario for a while. I just want to walk through it so we have a
shared picture of goals.
Item - Sharing between Desktop User and Hub Collaborator
1. Desktop user 'sends' an item to others. This means:
- Item is automatically published to Hub as a single item if it's not
already on server as part of a shared collection
- Read-write ticket is plopped into message body of the item (Desktop
users don't see it, but if you receive the message in your normal
email client, you'll see it.)
- If Desktop user doesn't have sharing account, they are prompted to
sign-up for one in order to share the item with a [x] Never show
again. checkbox.
2. Recipients receive message in their email clients where they see
sharing URL.
- They click on it and can edit the item in the Hub UI standalone
Detail View where they have option to add it to their account; OR
- If user is already subscribed to that item through a shared
collection or has already added it to their account, we should be
able to figure that out and take them to the logged-in view of the
item (basically jump-link to the item in their account, in the first
collection it appears in.)
Item - Sharing between Desktop users
1. First part is the same.
2a. Recipients receive message in their email clients where they see
sharing URL
- They click on it and Chandler Desktop automatically subscribes to
the time; OR
- If user is already subscribed to that item through a shared
collection or has already added it to their account, we should be
able to figure that out and take them to the item (basically jump-
link to the item in Chandler, in the first collection it appears in.)
OR
2b. Recipients receive message in Chandler Desktop where Chandler
detects sharing URL and automatically subscribes to item, or if user
already has item via Sharing, the message is zapped.
Does that sound like the right thing to do?
As for downloading email in general:
I think it would make sense to work towards supporting the following
scenarios:
- Support forwarding emails to Chandler Hub account
- Support downloading email replies to messages sent from Chandler
(so you have entire thread in Chandler)
- Open Issue: Do we support downloading messages from other Chandler
Desktop clients so that Desktop users can do item-sharing without
having to go through their email client?
It's also worth noting that by stripping Chandler emails of EIMML
attachments we will get rid of a number of conflict resolution bugs.
Is that correct Grant, Brian? Do we know which ones in particular?
Mimi
On Mar 7, 2008, at 4:09 PM, Grant Baillie wrote:
Hi, Mimi
I concur somewhat with Brian Kirsch's reply that the "something
radical" below would simplify a lot of the sharing interactions,
but also don't have much sense how important non-shared peer-to-
peer Edit/Update usage is. (It certainly is a rare case amongst us
hub-centric users).
If we did implement this, as I think Brian pointed out, we could
avoid sending eimml attachments with emails. On the other hand, it
would make POP accounts completely useless, since it sounds as if
you're proposing having Chandler not download any incoming email at
all.
Also ... individual item sharing. Sounds yummy :D, but probably not
by 1.0 I'm guessing.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
