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
