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

Phillip J. Eby pje at telecommunity.com
Thu Feb 14 13:42:23 PST 2008


Maybe I'm misunderstanding something about how the existing setup 
works, but wouldn't the simplest user model be that you *always* use 
some explicit "invite" mechanism in order to share your 
stuff?  Especially if that invitation mechanism just asks me for the 
email addresses of the person(s) I'm giving access to, so I don't 
have to know or think about URLs.  (Of course, if I've just created a 
collection on the server, or published one from the desktop, having 
some kind of prompt that the invite mechanism exists, or going right 
into it, would be a good idea.)

Then, on the receiving end, if I get an invite via email in the 
desktop, I should just be able to "accept" it to set up my 
subscription.  (Or of course, just click on the link to view stuff on 
the hub, if I'm using a different email client.)

Ideally, I shouldn't need to know or care what a "ticket" is, but 
post-1.0 it would be nice if it generated different URLs for each 
invitee, so that they could be individually "un-invited".  :)

Last, but not least, it'd be good if the hub had a way to download a 
file to initiate a subscription, using a shell association, so that 
if you go to the hub in a web browser (e.g., you got a ticket from a 
non-desktop user), you could just click in your browser to fire up 
the desktop and add the subscription.

I don't know if anything I just said is how practical to implement 
(especially for 1.0), or how it relates to what we actually do.  I'm 
just saying that as a naive user, that's how I'd *like* it all to 
work, or the way that would appear the most seamless and "low-maintenance".  :)


At 12:22 PM 2/14/2008 -0800, 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



More information about the chandler-dev mailing list