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

[Grant Baillie]

Hi, Mimi

Thanks for the reminder!

Option 2 and Option 1 are pretty much the same amount of work on the  
Desktop: Either way, we need cleverer code that creates the tickets  
under the right circumstances, and that deals with errors (e.g. server  
offline, etc). I could probably knock off the code in a day, with  
another day to test.

Option 3 is probably a half day of work, tops. But it's not what my  
gut thinks is The Right Thing. I'd like to feel we're making some  
progress down the road to a better thing, like Phillip's proposal.

--Grant

On 22 Feb, 2008, at 15:31, Mimi Yin wrote:

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