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

[Grant Baillie]

On 10 Mar, 2008, at 20:16, Mimi Yin wrote:

> On Mar 10, 2008, at 11:54 AM, Jeffrey Harris wrote:
>
>> Hi Mimi,
>>
>>> *Item - Sharing between Desktop users*
>>> 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;
>>
>> I'm not clear on what mechanism we'd use to get arbitrary mail  
>> clients to send URL clicks to Chandler Desktop.  We could  
>> conceivably use our own custom scheme (like webcal:// instead of  
>> http://), but that's both tricky to get right on all platforms and  
>> generally frowned upon.  Also, the link wouldn't work for casual  
>> collaborators, we'd need two links, which is confusing.
>
> I dunno if 2 links would be that confusing:
>
> View this note/event on Chandler Hub: http://...
> Subscribe to this note/event with Chandler Desktop: http://...

Except it wouldn't be http: in the second link, it'd have to be  
chandler: or something. Assuming we get it to work on all 3 platforms.  
I know the magic for Mac, but not Linux/Windows.

>> Failing a custom scheme, I don't think we can get clicking a link  
>> to take users directly to Desktop.  We could send them first to the  
>> Hub, or we could use a localhost link on a well-known port to talk  
>> directly to the Desktop, either way it'd open up a browser, it  
>> wouldn't take you directly to the Desktop client.

Especially if the Desktop client isn't actually running at the time  
you click ...

>>>
>>> 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?
>>
>> This approach is much closer to what we do now (we could maybe get  
>> by with just a custom header instead of an EIMML attachment, which  
>> might let Chandler emails get through Mailman).

We could also register an attachment type, so that opening the  
attachment would launch Chandler. It might even be possible to "embed"  
the attachment in a reasonable way in, say, html mail. Unfortunately,  
opening random attachments in email has gotten a bad name nowadays ...

> I think it might still be important to connect the workflow from  
> email. A header would be good.

Agreed.

>> The downsides are similar to what we already have; it requires  
>> configuring mail accounts in Chandler and it's magical (Chandler  
>> does something people don't expect, if they set up an account, they  
>> pretty much expect to get all their mail, or nothing).
>
> I don't think we're going to get rid of inbound email accounts tho,  
> if only to continue supporting the IMAP folder scenario.
>
>>
>>> - Support downloading email replies to messages sent from Chandler  
>>> (so you have entire thread in Chandler)
>>
>> I guess this could be made to work for people who use the all- 
>> messages-in-their-Inbox filing system, but I think it would be very  
>> expensive to make this work for all IMAP usage patterns.  I worry  
>> that doing this would look like not just magic, but unreliable magic.
>
> Not sure I'm following...Why would this be unreliable? Meaning,  
> people might file replies out of their Inbox?

I think Jeffrey is saying it would greatly increase the amount of  
traffic Chandler would generate to talk to IMAP servers, which would  
make fetching mail susceptible to network failures, etc. And, because  
of inconsistent server implementations, it might not work at all.

--Grant

>> So, I'm not sure we're on the same page about long-term item- 
>> sharing goals.
>>
>> Sincerely,
>> Jeffrey
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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