[Mailman-Developers] mailman 2.1a2 -- mailmanctl -- memory usage

[Barry A. Warsaw]

>>>>> "SB" == Scott Brown <scott-brown@home.com> writes:

    SB> In a perfect world, yes, that would be the best (I mentioned
    SB> this on the wikki)... but if you were to look at sliding vhost
    SB> support in gradually (which is a reasonable expectation
    SB> considering how much could be upset in an all-or-nothing
    SB> change set) then I dont see a problem with the
    SB> unique-list-names-per-server approach at this time (I've got
    SB> that same limitation on my prod server right now with the way
    SB> things are setup...  no-one seems to care about that
    SB> limitation... and I'm sure that knowing that v2.2 (or v3.0)
    SB> would have this restriction removed would placeate most people
    SB> who might get their shorts in a knot).

Cool, I can live with that too, then! :)

    SB> I guess it falls back to the business model.  Of course, if
    SB> you're REALLY wanting to make an inroads into a vhosting
    SB> environment, then you'd also need to be able to configure the
    SB> max lists allowed per domain.  Me - personally -
    SB> "IDontCare"(tm) if someone has 1 or 100.

I have plans on how to do this, and support something that Chuq's
talked about a lot.  The idea is that you really have these levels of
control: site -> vhost -> list (are there more?).  You want the site
admin to be able to say "I'll let my vhost admins change option W and
X, but not Y, and limit Z to from 1 to 100".  I believe that's doable,
but definitely not in the MM2.1 time frame.  Next year. :)

    >> - DEFAULT_HOST_NAME vs. DEFAULT_URL.  Each vhost is identified
    >> by both variables (e.g. mail.python.org and list@python.org).
    >> So you need to create a mapping of vhost to those two
    >> variables, and use the right one in the right context.

    SB> True enough - but both are (something)python.org.  Right now,
    SB> unless you override things, you get default_host as 'hostname'
    SB> and default_url as http://'hostname'/mailman/ ... spitting the
    SB> vhost name into either one is a heck of a lot closer than
    SB> 'hostname'.

    SB> And it would only be necessary on creation of new records, no?
    SB> Once the data's there, it could be modified by the user, so
    SB> current processes would (to my mind) still hold up.

No.

What we're talking about are the list config attributes web_page_url
and host_name.  The former gets used in all generated URLs, such as
http://mail.python.org/mailman/listinfo and the latter gets used in
all email, e.g. mailman-developers-request@python.org.

Anyway, it's way too dangerous to let list admins muck with
web_page_url, since it's trivial to make their lists non-functional.
And I see no reason why they should be able to muck with host_name
either.  So both are frozen when the list is created (of course, they
can always be changed via bin/withlist.

So, the new deal is to define the web_page_url/host_name (really, the
host that is embedded in web_page_url) mappings in mm_cfg.py with
calls to add_virtualhost() and then everything should work fine from
there.

    SB> MM2.1 is already including a number of goodies that will be
    SB> useful... and I'm probably as anxious as you to get a release
    SB> version out...

Probably not. :)

Cheers,
-Barry