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