Hi Phillip,
I agree the workflow you describe is ideal. We never got around to
implementing this functionality and are unlikely to in the near
future. But this is definitely what we should shoot for as we iterate
going forward.
Mimi
On Feb 14, 2008, at 1:42 PM, Phillip J. Eby wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
