Replying to Sheila's prompt below...
On Jul 11, 2006, at 5:02 PM, Sheila Mooney wrote:
On Jul 11, 2006, at 1:30 PM, Jeremy Epstein wrote:
Hey all-- my comments below.
So the proposal above would actually require something like this:
1. Email the people I want to share with and tell them to go
create an account on cosmo.
2. Ask them to please email me back with their usernames
3. Enter people's usernames into Chandler and assign ACLs to each
account (requires additional UI work)
4. Enter people's email addresses and fire off an email to invite
them to share and to point them to the share
no! no! no! Imagine this:
you enter a list of emails to invite and chandler/scooby handles
the rest:
(1) it looks to match users to emails in the cosmo DB,
(2) if matched "do the right thing" if not, create a new account.
username == email
(3) send email to all these new users
(4) when the new user gets to scooby and attempts a non-read
action, we prompt for them to enter their email and password.-- we
offer an affordance for new users to choose a password.
All of this implies that chandler and scooby can do what every
other app on the web does-- send automated emails.
part of this is colored by the notion of what it takes to set up
an account, and assign permisions. Lets say for the sake of
argument the following:
1) your username and email are the same
2) if there is no account match to an email, we implicitly create
one -- there is no sign up involved.
3) we implicily assign very basic edit permissions to all
invitees: "you can only edit or destroy events you create", "you
can only accept or reject events you did not create". You do not
need to have a user maintained infrastructure to set up these
acls-- they are "built in" to the behavior of sharing and ownership.
Seems to me like we talked about this when I first started at OSAF
and decided this wouldn't work well. I can't remember all the issue
but I would like to get Lisa to chime in since most of these
discussions were with her. We used to have a sharing invitation
detail view where people entered email addresses and we ended up
getting rid of that to do something really simple - 2 tickets.
A couple of things I remember...
1) People may have more than one email address. They might be using
multiple email accounts in Chandler - I am right now.
2) What happens when people's email addresses change? How do I
reconcile that with the account name I have setup
3) If I enter an email and it doesn't find an account match, it
creates a new one. What if I already have an account but someone is
using one of my other emails...now I have 2 accounts?
4) For this automatic account creation - how to we deal with
passwords?
Yes indeed. None of these were insurmountable problems, potentially,
but they all required more user interface and other programming work
than using simple tickets. For example we could totally build a user
interaction to allow me, whose account was registered as
"[EMAIL PROTECTED]", to receive an invitation to share something
to "[EMAIL PROTECTED]". That user interaction might be that when I
click on the link sent to "[EMAIL PROTECTED]", it prompts me to verify my
email address and choose a password, OR if I already have an account
to log into there, then verify the [EMAIL PROTECTED] address and add that
new address to the existing account. Then we'd have to have some way
of merging two accounts in Cosmo, or perhaps have two different kinds
of accounts (full, verified accounts and potential unverified
accounts) and a way to remove one and assign its permissions to the
other.
Except for the spam/privacy considerations that have already been
mentioned, It's just work. But it's more work than tickets (requires
slightly more complex ACL support, which we didn't have then), and
might be less usable than tickets even with more work. (Maybe
somebody could implement a generic way of doing this in Apache,
although it's always hard to integrate generic account/authentication/
acl features into specific applications.)
Lisa
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
