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

[Scott Brown]

> >>>>> "SB" == Scott Brown <scott-brown@home.com> writes:
>
>     SB> The only thing that I've run across that causes me headaches
>     SB> is the fact that (on the drop I've been playing with) new
>     SB> lists are created with the system name, not the name of the
>     SB> vhost which is requesting it.
>
> Are you using bin/newlist or thru-the-web list creation?  bin/newlist
> supports a syntax for listnames that specify the vhost to use, and
> thru-the-web should decipher the vhost specified in the url (but that
> may be buggy).

thru-da-web :)  I sent you a mention of this bug a week or so ago (you might
have been on vacation then :)

>     SB> Perhaps #1 could be done easily by examining where new data is
>     SB> created and a domain name is required, and using the vhost
>     SB> domain from the requesting url, rather than the system name
>     SB> (watch for proxy'd requests though :) Command line proggies
>     SB> would then need to be able to specify a vhost on the command
>     SB> line with a new switch.
>
>     SB> A pro like you should be able to knock that off in a couple
>     SB> days, no?
>
> I think figuring out the right vhost to use is tractable, but there
> are a few issues that, while not terribly difficult, will require a
> lot of tedious code hackery and testing:
>
> - List databases are all stored in the same "namespace"
>   (i.e. directory) in $prefix/lists.  The vhost would have to be
>   encoded in the path, either in a subdirectory, or by encoding it in
>   the list's directory name (which is a lot of work because then
>   MailList.internal_name() doesn't point to the directory).

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

I dont think that the people who have been performing full installs per
vhost would be upset by a gradual insertion, since they're treating each
host uniquely anyways.

> - To do this The Right Way, you really want to allow the site admin to
>   set up different defaults for each vhost.  You're probably talking
>   about a separate mm_cfg.py-style file for each vhost, and
>   architecting that and updating all the code isn't a trivial amount
>   of work.

Why not just accept the system defaults, except where it's vhost relevant?
Granted, even my production server has a limited userbase, but I know I'd
set up all hosts the same from the start (though others might not).

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

> - 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.

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

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

> Looking ahead at the time available to finish up MM2.1, I just don't
> see it as being feasible.

Heh... worth a shot :)

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