Yes, that was my understanding as well. What I'm asking is: Instead of thinking of the URLs themselves as the source of functionality, could we make the web and desktop clients smart enough to put 2 + 2 together and 'deduce' the /mc/ URL from the ticket URL (which identifies the collection) and the user's Hub account info.

Mimi

On Sep 18, 2007, at 2:39 PM, Morgen Sagen wrote:

bcm can correct me if I'm wrong, but the only reason a user ever sees
an /mc/ URL is that a /pim/ URL doesn't support basic
(username/password) authentication.  If it did, we wouldn't ever need
to expose /mc/ URLs.

~morgen

On 9/18/07, Mimi Yin <[EMAIL PROTECTED]> wrote:
There's been some confusion around how Hub users should access / generate
ticket-URLs for sharing.

Currently there are 2 URLs end-users are exposed to. The first is
well-known: the ticket-URL, which allows users to view collections in
Chandler Hub and subscribe to collections with Chandler Desktop without an
account.

The second is less-known. It's the URL with /mc/ in the middle of it. It's intended for Chandler Hub users with accounts and provides them with a way
to bookmark collections and/or subscribe to collections with Chandler
Desktop that requires authentication. In other words, it's more secure *and*
Chandler Hub can tell *who* is editing items when subscribers edit
collections from Chandler Hub. By contrast, when Chandler Desktop
subscribers who don't have Chandler Hub accounts subscribe to shares with
ticket-URLs, the server can't identify them when they make edits.

The distinction makes a lot of sense...once you understand how it all works. But I think it can be confusing to navigate the different URLs and the
different ways to subscribe and share without that context.

Why are there all these different ways to subscribe to the same collection?

The 'ticket' versus 'mc' URL expose something to the user that the web and
desktop clients should probably handle *for* the user.

What if instead of presenting users with 2 different kinds of URLs, we're
simply 'smarter' about the way we handle the ticket-URL.

If you access a collection you've already added to your Chandler Hub account and you're logged in, we should directly re-route you to the 'from your
account' view of the collection.

This is already logged as:
http://bugzilla.osafoundation.org/show_bug.cgi?id=10776

We're currently 'sort of doing this' on the Desktop. If you've filled out a
Chandler Hub account, even if you subscribe to a collection with a
ticket-URL, the server is able to identify you (if not your specific Hub
account) when you make edits because the client sends your account
information along with your edits. This doesn't always work though because the client simply sends account information from the first email account in the accounts dialog and you may not have any email accounts. We could do a
better job of matching up shared collections with their corresponding
sharing accounts.

(The ultimate solution for the Desktop is to automatically sync up Chandler Desktop and Chandler Hub as soon as users enter their Hub account info into Chandler Desktop. Forcing Chandler users to subscribe 2x, once in Chandler Hub and a second time in Chandler Desktop is really a hack from a workflow perspective. But I will reserve that for a different proposal/ thread.)

The gist of it is: Can we shift the burden of understanding the difference
between the ticket and /mc/ URLs from the user to the web and desktop
clients? If we can pull that off, then we can have a single interface for providing URLs. In other words, the URL the Hub account holder uses to subscribe with Chandler Desktop should be the same URL they pass to friends
and colleagues to subscribe.

Mimi

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to