>Sure would. It's something I'd like to see happen down the road, if
>only from the situation of easing things for the user. You could
>disassociate the zubscription from the e-mail address, allowing a user
>to take an account/password, assign a delivery address to it, and then
>choose zubscriptions on a site-wide basis. someone moves, they don't
>need to remember all the lists and update them all, it's all in one
>place, one change. It really simplifies it from the point of view of
>the user. they now have a site account, rather than 1 to N
>zubscriptions, and you can build some really nice administration tools
>to work with them on it.
We're very keen on this approach - it's one of the main things I'd want to
sanitise between how our web stuff and majordomo works. Having all the
majordomo stuff in an SQL database will help us do this as we can more
easily layer things on top of whatever mj2 does but having the concept more
naturally part of mj2's way is better.
Basically you have a distinct user registration system within mj2 - each
user then get's a uid and it is *this* that get's (internally) "zubscribed"
to the mailing list (along with params indicating things like which of the
user's email address should have mail sent to it, does this user have
posting rights or is read only etc. - to be discussed). The problem is
that this is a more radical departure from the original mj1.x way.
>It has some complications, especially if you're doing virtual domain or
You need to be very clear about shared / non-shared name spaces for the
usernames. We normally call these "clusters" (i.e. you cluster user details
where each cluster has it's own uid namespace). People's uid+clusterid is
thus unique and you either make sure that the clusterid is made available
when people are doing things that needs access control or you infer it
somehow. The obvious way to be able to infer it is to say that when you
create a new virtual domain you assign it to a single given "cluster". As
an aside - we'd also like to ensure that clusterid's are Internet wide
unique and then at some point accommodate cross cluster interaction across
the whole net (hooking into http://www.w3.org/P3P/) ...
>want to keep some stuff separate, but trying to build fewer, global (or
>mostly global) data sets can really add power and flexibility, and
>reduce confusion and complication for the end user.
One of the main dangers is that this can make things harder (initially) on
the end user. I think it's vital that a new user can come in and mail a
"zubscribe list1" message to majordomo@domain.com and it just works. We
don't want them to have to go through any more hoops. The way I'd reconcile
this with the desire for a global user registration system is to auto set
up new accounts for these people and provide the means for accounts to be
merged if the user considers it useful enough. I could discuss this a bit
further but I don't really have time at the moment and I'm probably
incoherent/off track anyways :)
>We've actually been
>looking at this as a long term requirement for some of the corporate
>things, where we integrate the server functions into a customer
>database, so users can do EVERYTHING having to do with the company
>(lists, product registration, whatever...) from a single site, with a
>single account/password. that's ultimate integration on an
>enterprise-caliber level, and definitely a goal, not a project, but
>adding in hooks to suport it, or building tools that bring that kind of
>integration into tools like majordomo, are definitely first steps.
We've got much the same aim/approach that we've been slowly progressing
down for a couple of years now (at a guess, we don't have as much
justification to spend the time on it as you - it's more a case if it being
something we're interested in).
References:
|
|
