[Proposal] Goals for Item-Sharing vis-a-vis: Re: [Last call] Re: [Chandler-dev] Shipping ticketed-URLs around for individual items via email

Mimi Yin mimi at osafoundation.org
Fri Mar 7 16:44:44 PST 2008


(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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20080307/26760f9b/attachment.html


More information about the chandler-dev mailing list