[Design] Re: [Cosmo] Reconciling various sharing URLs

[Mimi Yin]

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 <mimi at osafoundation.org> 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