I've attempted to summarize the 'design' issues that have been flying around on this thread. What's missing? What's inaccurate? We don't need to make a decision on these issues right away. I'm just trying to capture what all of the issues are so we can fairly evaluate this proposal wrt the other bridging the gap options. REQUIREMENTS Make it easy for Casual Collaborators to add items to shared collections via email. This implies: + Setting up a single persistent email address for the collection. Having too many email addresses for each collection or having email addresses that change constantly would place too much of a burden on the Casual Collaborator. + Don't enforce a strict syntax (e.g. /Task, /Event) for creating new events + Don't require a password + Burden of regulating SPAM should be placed on the Hub/Coordinator/Assistant, the people who set up these shares and/or get the most out of these collaboration scenarios, aka Chandler desktop client users. === Customization / Personalization + Allow users to define / change their own email addresses: only LHS? or the entire email address? + Allow users to turn off this feature - This is in conflict with using the email address to 'label' email submisssion with metadata. - However, it would be a way for users to control SPAM. - Also has 'cool' factor === Minimizing SPAM. + Whitelisting + Quarantining + Some combination of both: Build a whitelist dynamically by quarantining email submissions and then whitelisting email addresses that are approved. === 'Labeling' submissions with metadata: + What Kind is this item + What Collection(s) should this item be added to This issue is related to: Partition namespaces. This implies: + Allowing users to define their own email addresses; OR + Setting up a structure for auto-generated email addresses Options: + Specify Kind in the LHS of the email address: + Specify shar-ER's account in the RHS of the email address + Specify the collection in the RHS of the email address e.g. [EMAIL PROTECTED] - Don't worry about items stamped as multiple Kinds for now - There are limitations around what constitutes a valid email address (e.g. no spaces, invalid characters, etc) + Define syntax for labeling items in the subject line or body of an email: /Task /Event /Mail /Label: Home /Start time: 4:30PM PST /Location: Avalon + Parse contents of email to figure out what it should be |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
