| On Aug 21, 2006, at 4:46 PM, Brian Moseley wrote:
I realize there is huge amount of development work to add ACLS before beta. I guess what I'm unclear about is how much ACL work is really needed for post beta and has anyone investigated how to phase this in? After having a better understanding of the mission and goals for the beta release, adding a password doesn't necessarily solve any additional issues. In fact, it adds development time (though it may be minimal it still adds some development time) and adds complexity and inconvenience to the user. For example, what happens when the users forgets their password? This happens frequently. How will they retrieve new one? Does the 'Sharee' have to keep pestering the 'Sharer' for the password if they keep losing the password? If the longer term is to add in ACLs why not try to find a solution that brings us closer to the end goal? If the first option is a 'trust' model and that is part of the mission and goal of OSAF then my vote would just go to option 1. If I could interject with another option which I'll name the 'accountability' option, it might work a little like this: + When a user wishes to publish a calendar they may require anyone who uses the calendar to sign up for a Cosmo account. This becomes a property of the calendar, independent of the tickets. + Tickets work pretty much the same as they do in the current 'trust' model with a notable exception + Upon clicking on a ticket to see a calendar, the user is presented with a dialog that says the calendar requires the user to sign up for a Cosmo account (i.e "this is a secure calendar, you will need an account to view"). Reasons for this option --Pros + It's still keeps the original goal of the 'trust' community. + It introduces a notion of accountability when a calendar creator wants it + Users will create accounts because a sharer wants accountability, not because of a demand of the software. + This is a step in the ACL direction where users would be accountable and potentially need permission + The 'Sharee' would not have to store their collections in their e-mail - the account is a good way to access all of your subscriptions without having to keep all of the sharing tickets you received. --Cons + You're not actually password protecting anything (yet), you're just setting the stage for it. -Priscilla |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
