[Mailman-Developers] Users, persistent storage, caches, etc.

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 6, 2006, at 1:19 PM, emf wrote:

> Barry et. al.:
>
> Barry, I've read about your SQLAlchemy work and look forward to seeing
> that checkin ;)

Heh, if only it worked.  I've got a message sitting in my queue from  
their mailing list so I'm going to give it another go after I merge  
my locally committed other changes to the trunk (hopefully tonight).

> 1.) I have to have a concept of user to really improve the user
> interface. Many things become easier, but there are things I can do  
> with
> a user-concept I can't do without it:
>
> a.) Different emails for different lists, same user.
> b.) Providing moderator/admin privileges to a user rather than a  
> shared
> secret.
>
> 2.) I need to store preference information somewheres. This includes:
> site-wide UI configuration; list-wide UI configuration; user UI
> preferences/state.
>
> 3.) I need to store caches somewhere; for some things it would be best
> to keep them around, and maybe even in a more queryable format than  
> files.
>
> All of this leads me to- where should I stick things?

Well, that's a good question, because the biggest feature of the  
mythical Mailman 3 is a unified user database.  There simply isn't  
anything like that for Mailman 2.  Each list, list archive, and  
member database is a silo and unwinding that is way too complicate to  
tackle for MM2.  All the 'global' features currently visible in the  
options page are really hacks, requiring iteration through all  
mailing lists in order to imitate a global user database.

To do it right requires hashing out a lot of issues, some of which  
have been discussed on the MM3 list or at sprints, but none of which  
are really functional. For example, should each domain on a server  
with virtual domains be a silo?  (You'd need another level in point  
#2 above which represents the domain).

Mailman really doesn't have a user-centric architecture and I think  
it's going to be difficult to wedge one in.  It's worth discussing  
further though.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iQCVAwUBRK22V3EjvBPtnXfVAQLpRAP+K5Ff7K0+5Mvwnc+Rcq7iVj9mtmjHs3kV
/pOMzpWkWKKtt/JWlPXX6ml2n5ODXP6Nq/CRyYbwFl1xQyDCYiQ64WohJnJW4gQX
8dybLtWKlGTF4WPBd/Ey8uCGF/o4t2YZaiQC3C9wQql8rUMpd5JHCfYADxEAJtVC
VyuE7lSyC0I=
=IneM
-----END PGP SIGNATURE-----