[Mailman-Users] setting up the mailing list

[Barry Warsaw]

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

On Apr 8, 2009, at 1:45 AM, Stephen J. Turnbull wrote:

> Mailman itself will not, but one goal of MM3 is to provide a standard
> connector architecture for backend databases which supply at least a
> name and email address but probably do a lot more than that.

> People who are interested in this feature should look at the MM3 stuff
> on the wiki and the MM3 code and documentation, then ask Barry what
> his plans are.  It should not be hard to add further elements to
> web-based forms (for one example) that feed names and addresses to
> such a connector.  Then Mailman itself would ignore that additional
> information (absent local extensions), merely providing a single
> communication channel for list managers to access the backend
> database.  Most of the effort would no doubt go to providing sane
> error messages in the case where the backend's schema doesn't support
> the additional fields, and stuff like that.

Stephen's basically correct.  In Mailman 3, the core engine operates  
on components, essentially objects that implement a formal interface.   
There are three "stores" of data, user data, list data and message  
data, with loose connections between them (think: no foreign keys).   
Thus you could, in theory anyway <wink>, store the user data including  
subscription information in your CMS, and let Mailman handle list- 
specific data.  Of course, you could re-implement the backends to  
provide the defined interfaces anyway you wanted and then Mailman  
should operate without regard to where the data lives.

I won't go into more detail here.  If you're interested in  
participating more in the development of Mailman 3, please join us  
over in mailman-developers at python.org.

Barry

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

iEYEARECAAYFAknciqAACgkQ2YZpQepbvXHLQwCfTtSHutL3bIjLetYHmS5ZidyG
HWMAnikoDJZO+tXWS5JemHgE3glvLHZ4
=+1pY
-----END PGP SIGNATURE-----