See in-line below:
On Jul 19, 2006, at 6:47 AM, Jared Rhine wrote:
+ How do addresses map to calendars? (1-1, 1 to many, many to 1)
What are reasons for having multiple addresses per share?
Probably different operations per share. One alias for all-day event
submissions, one alias for regular events, one for free-form items,
one for
SMS. One for deletions, one for searches. Ideas only, for
clarification;
not proposals. I realize these other operations are not relevant
to the
discussion of the "email submission" case.
So something like:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Would we be able to accept all permutations? maileventtask?
taskeventmail?
+ How are new addresses created?
Auto-generated when a collection is shared.
Ah, you've moved on to a specific implementation model, ok.
What scheme do you propose for address creation? I suspect we must
include
both components of the user -> collection pair. Probably
concatenated with
punctuation: "jared.work@" and "jared.personal@" perhaps. Your idea?
That might work. There are cases where you're not sharing a personal
collection, but one for the group. e.g. osaf.calendar...But we can't
probably get over that in the short-term.
I'm tempted to allow users to personalize these email addresses in
whatever they way they want. My preference for automation was
motivated by my assumption that it would be easier to implement (less
UI).
SMTP format addresses have certain restrictions on syntax. Do any
SMTP
restrictions (punctuation, no spaces, perhaps internationalization
problems)
now become restrictions on the names of collections? Probably
not. So
there's at least some mapping step between the two. I bet any
proposed spec
starts with "strip whitespace" :) Not sure what else is needed
offhand.
But I can't help think the user needs some control over this; if my
Chandler
share name is "Work (client)" or something, perhaps the person
would like to
be able to select the string that maps to in email (I think
parentheses
might be out as an allowed character too, btw). I suppose the same
problem
exists for any URLs you want to hand out to ("private" name used
now becomes
visible by others). I'd guess our answer is to set the hassle
aside and
make them name their collections the way they want the email to
appear?
We could do this in the short-term and see what interesting use cases
we run into.
Brian mentions the "leaked address" problem as another motivator
for wanting
to be able to set and change the email alias used.
Yes. How quickly do you think this might happen? Can we implement it
in a following release? Or are leaks likely to happen right away? In
other words, how often will users need to change collection email
addresses?
If the email address is shown in say a Chandler dialog, I wonder
how it
determines what to display. Did it ask the server for the name
assigned and
use that? Did it present a dialog to the user, with
whitespace/known-bad-email-characters stripped out, and ask the
server to
use that address for this collection? Who's driving?
Do you mean who's driving, client or server?
Does the user get to select whether an email address is
autocreated? A user
might reasonably wish to decline submissions. Indeed, they might
wish to
turn it off and on as an administrative function later.
Yes, all possibilities.
Feasibility? Not convenient given current architectures, but
there's at
least a few different ways to implement "auto-creation" of the
address. We
could go again for tight Cosmo integration. During collection
creation and
deletion on the server, Cosmo could update a relational table of valid
submission email addresses and the collection URLs they map to.
The MTA and
email robot would then look up in this table for each email submission
processed.
So is it easier to build UI to have users pick their own email
addresses?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
