[Mailman-Developers] Re: TOPICS

[Harald Meland]

[Paulo Eduardo Neves]

> Harald Meland wrote:
> > Anyhow, I guess that implementing this would be a lot easier (and
> > cleaner) if every list member had some "user objects" -- and that is
> > planned for after 1.0.  So I guess we'll think about it all until we
> > have the infrastructure to implement it on top of in place.
> 
> I've read in the TO-DO list about User profiles, is it the same of user
> object?

Not quite, but they're not unrelated, either.

> Could you explain the idea behind it? 

Well, the motivation I have for implementing "user objects", is that I
don't want one particular user that is subscribed to several Mailman
mailing lists (on the same Mailman installation) to have to remember
one password per list.

If Mailman had an installation-wide database of all members subscribed
to any of the lists, and each list had "pointers" pointing to specific
user objects in this database (meaning that the users corresponding to
the pointed-to objects are members of the pointing-from list), the
user password could be kept in the user object instead of with each
list.

You'd also get a lot of other benefits from this, of course:

 * User objects could know about the different mail aliases belonging
   to one user (meaning that Mailman would know that
   `hmeland@usit.uio.no' and `harald.meland@usit.uio.no' were really
   the same user, which is very handy for "restrict posting privilege
   to list members")

 * Admins are users as well -- thus their _single_ admin password,
   which would work for all the lists they admin, could be stored in a
   (special) user object.  Lists with multiple admins wouldn't need
   their admins to share the single list password anymore.

 * If some person changes email address, update the person's user
   object -- and all the mailing lists the person is a member of
   automatically goes to the new address.  Ditto for disabling
   delivery when going on vacation etc.  Having separate settings for
   different lists should of course remain possible.

... just to mention a few things.

None of this is set in stone, of course -- these are just some ideas I
have, nothing has actually been implemented.

"Member profiles", I think, means that you each user can organize
their subscriptions into hierarchies (within their user object) --
thus, any changes made to the root node in the hierarchy gets
inherited by all your subscriptions.

Example:

 * Root node
   |
   * Python mailing lists
     |
     * "Mailman-users" subscription options
     * "Mailman-developers" subscription options
   * Work-related mailing lists
     |
     * "postmaster" subscription options
     * "hostmaster" subscription options
     * "webmaster" subscription options

  Your local mail system has recently been upgraded to support
  addresses of the form `username+suffix@example.com', signifying that
  mail to this address goes directly into your IMAP folder called
  `suffix'.

  You want to use separate mail addresses for the python lists and the
  work-related lists -- so you enter each of these "member profiles"
  and update them, and the changes propagate down the tree to the
  different lists.  Voila :)

> I believe it would solve well a problem I have. I have an announcement
> list where I send messages about a lot of topics. Not all topics are of
> interest of all subscribers (i.e. Joe doesn't want to know about events
> in other state).
> 
> It looks like user profiles (or Topics) would solve this problem.

Topics are not the same as member profiles.  The (hypothetic) user
"Topics" setting are meant to signify what subset of messages you want
to receive from a topic-enabled Mailman list, while member profiles
are for specifying defaults for subsets of your list subscriptions
(regardless of whether the subscribed-to lists are topic-enabled or
not).

I was merely stating that for implementing topics, one needs to keep
so much user-specific information (on what topics are deemed
interesting) in Mailman, that keeping off implementing it until
_after_ the introduction of user objects (which will provide a handy
mechanism for storing user-specific information) would seem like a
smart move.
-- 
Harald