Mimi Yin wrote:
> So something like:
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]

Something like that, perhaps.

I should clarify that anything we do with the right-hand-side needs to be
customized at the 3rd level of the hostname.  [EMAIL PROTECTED] not
[EMAIL PROTECTED]

Doing stuff with the right-hand-side is technically more challenging.  If
it's not compelling, at least in Beta timeframe, I'd probably rather pass
and get the fundamentals right.  But it is doable and can add value in
clever ways.

It's very helpful to have some sort of separator between the parts, if
you're adding semantics to the structure.

We don't have to have this extra structure.  If everyone just picked an
email submission name for their published collection, you could have
[EMAIL PROTECTED]  First-come-first-served; if someone else has the name, you
need to pick a different one.

> Would we be able to accept all permutations? maileventtask? taskeventmail?

Most anything is possible.  My first email on the topic was very general
because you can slice this plain string in so many ways.  If both those
permutations you mention are supposed to do the same thing, then yes, we can
do that.  The namespace of the email addresses can have two (or 10) strings
"point to" the same action (submit as task to collection FOO under account BAR).

We have to build this table of what email address map to what action.  We
have wide freedom in what goes in that table.  (And "table" is probably
literal; we'll have a database table with the entire list of valid email
addresses).

>> What scheme do you propose for address creation?  [...]
>> "jared.work@" and "jared.personal@" perhaps.

> 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.

What I did in practice was create an account for the group I managed,
"kei-it".  It got its own account, email, username, password, and URL
namespace.  I set up a new account in Chandler, put in the name/pw/URL, and
published a dedicated collection to that account.  Then created tickets on
those .../kei-it/Team calendars and sent them around.

Most office calendars published have been attached to specific people, and I
always wondered about it as a general practice.  If it shows up in URLs and
emails and such, I imagine quite a few people will create group accounts.
(And maybe have problems because you can't have two Cosmo accounts with the
same email; grrr.)

> 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).

That's what I lean towards as well.  The various threads have outlined why
you might want to rename them, etc.  It does require a UI to be built.

If you're looking for a recommendation in all this namespace stuff, I'd
probably say the most elegant design I can see right now is this:

+ Have a root, service hostname: osaf.us
+ Have each account get their own 3rd-level domain: 543howard.osaf.us
+ When publishing a collection, you get to select the name you use:
- [EMAIL PROTECTED]
- [EMAIL PROTECTED]
+ You can change the email submission address later.  If you change it in
the UI, the old name disappears and the new one becomes active.
+ You can choose to not publish any address for your collection.

>> Feasibility?  Not convenient given current architectures, but there's at
>> least a few different ways to implement "auto-creation" of the address.

> So is it easier to build UI to have users pick their own email addresses?

Not, building a UI is harder I think.  I was speaking mostly about some
various options about how to store the email submission address chosen and
how to make it always 100% up-to-date (versus say a 5-15 minute possible lag).

-- Jared
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to