Generating tickets to share collections. Re: [Chandler-dev] [Proposal] Web UI Work Q

[Mimi Yin]

Grant, when convenient could you comment on the relative difficulty  
of the 3 options below?

On Feb 14, 2008, at 12:28 PM, Travis Vachon wrote:

> The last option sounds like the most amount of work in the web ui  
> and in the server (I can't speak to the desktop). My order of  
> preference is:
>
> 1) Option 2
> 2) Option 1
> 3) Option 3
>
>
> -Travis
>
> On Feb 14, 2008, at 12:22 PM, Mimi Yin wrote:
>
>> Okay, I thought about this some more and I think it might be a  
>> little more complicated.
>>
>> First, let me re-iterate what I think we've agreed to so far to  
>> make sure I understand it. Right now we are proposing 2 models:
>>
>> 1. On the Server / Hub, we don't automatically generate sharing  
>> tickets. We only do so if the user asks to.
>>
>> 2. On the Desktop, we do, with the caveat that if an user created  
>> a collection on the Server/Hub and then syncs it down to the  
>> Desktop, they need to explicitly ask for tickets.
>>
>> Practically speaking this means doing the following work on the  
>> Desktop:
>>
>> 1. If a collection was created in the Desktop and published to  
>> Hub, today's behavior stays the same.
>> 2. However, if a collection exists on the Desktop as a result of  
>> having been created on the Server/Hub, then we do the following:
>> + Generate tickets if the users goes to Share>>Invite...
>> + Replace the [Copy URL(s)] button from the Manage Share... dialog  
>> and replace it with an [Invite...] button that effectively takes  
>> you to the Share>>Invite... dialog.
>>
>> {OR}
>>
>> We could make it so that the Server/Hub and Desktop have the same  
>> model: Neither automatically generates sharing tickets unless the  
>> users asks explicitly. For the Desktop, this means:
>> + Don't automatically generate tickets when publishing  
>> collections; INSTEAD
>> + Replace the [Copy URL(s)] button from both the Publish... and  
>> Manage Share... dialogs with an [Invite...] button; WHICH
>> - Generates 2 sharing tickets; AND
>> - Pops up the Share>>Invite... dialog.
>>
>> {OR}
>>
>> As Jared suggested we could simply add an option to the 'Settings'  
>> dialog so that users can 'turn off'  auto-ticket generation and  
>> defer the 'at-will ticket request' functionality.
>>
>> I'm wondering if this last option = least amount of work for both  
>> Server and Desktop. But don't have to decide right now what we  
>> should do.
>>
>> Mimi
>>
>> On Feb 14, 2008, at 11:39 AM, Grant Baillie wrote:
>>
>>>
>>> On 14 Feb, 2008, at 11:00, Mimi Yin wrote:
>>>
>>>> Grant, there is a question for you re: generating sharing  
>>>> tickets for collections created on Chandler Hub/Server.
>>>>
>>>> On Feb 13, 2008, at 4:28 PM, Travis Vachon wrote:
>>>>
>>>> ...
>>>>>>
>>>>>> We could:
>>>>>> + Add an 'Invite...' link which would generate 2 tickets in  
>>>>>> the 'Collection Details / Sharing dialog.
>>>>>> + I think we would also need to automatically generate 2  
>>>>>> tickets if the user invokes 'Invite' from the Desktop
>>>>>>
>>>>>> I was looking for the cheapest solution possible. FWIW many if  
>>>>>> not most Desktop users publish collections to the server, not  
>>>>>> to share with others, but just to back it up for their own  
>>>>>> use. So I'm not sure if this distinction between shared versus  
>>>>>> not shared is that clear. Or if it is, we should offer it for  
>>>>>> the Desktop as well.
>>>>>
>>>>> Yeah, especially given the security model changes Randy is  
>>>>> working on I think the cheapest solution is the one I proposed  
>>>>> since it doesn't require any server work and requires a minimum  
>>>>> of client work. Basically, we'd make the ticket creation  
>>>>> process transparent and on-demand when users want to share  
>>>>> calendars read-write.
>>>>
>>>> Hrm, so I think to solve the user workflow problem we'd mostly  
>>>> have to tweak the Desktop. Basically, create tickets when the  
>>>> user invokes Share>>Invite... Grant, does that seem reasonable?
>>>
>>> Eminently reasonable. Implementable, even!
>>>
>>> --Grant
>>>
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> 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