On 13-04-18 8:03 AM, Richard Wackerbarth wrote:
On Apr 18, 2013, at 1:19 AM, Florian Fuchs <flo.fu...@gmail.com> wrote:
1) It should be self-contained.
Meaning: It should not depend on any
mailman/mailman.client/postorius/hyperkitty packages.
Agreed
I agree about not needing postorious/hyperkitty, but I think a case
could be made that interdependence with mailman core and mailman client
might make sense.
I would advocate that this "User" module make it appear as if stores the entire
"record" for the user.
In the implementation, it could actually store parts of the user information in
multiple databases (one of which could be the MM-core).
This would also allow the option of having the MM-core become a client of this
User module, just as it now relies on an external message store.
Two options occur to me:
1. The user module is what mm-core uses for all user stuff.
I thinks case, case we have to be *much* more conservative about
dependencies. I think Django would be right out as a dependency for
Mailman core, for example. Plus, we're going to have to care a lot more
about speed and all.
2. The user module reads from mm-core and augments it.
This gives us the ability to supplement mm-core without impeding speed.
We discussed possibly filling in the blanks with respect to things like
the user preferences (which are currently set by membership, by user and
by email address... but a lot of those return an empty set when queried
if nothing is set directly there...) so this is maybe something we
already want.
Conceptually, #1 is probably easier because everything will be in one
place, but if we do #2 right, we can make it just as conceptually easy
for HyperKitty/Postorius/etc. without impeding Barry's core dev at all.
That does mean in case 2 that Mailman Extraneous User Stuff is going to
depend on Mailman Core, though.
My preference is #2:
a) It doesn't add any dependencies to Mailman core.
b) It doesn't require big changes in Mailman Core. Given that core is
pretty much ready to release, now would be a bad time for changes, and
I'm just not sure we can justify that amount of work for the types of
features that will be built on the extraneous user stuff.
c) It will be much easier to rip this out and replace it when we better
understand our actual needs. (e.g. Right now, I think a case could be
made that a quick mock-up in django would be fine, but I suspect that
requiring django for some potential applications would border on ridiculous)
We're probably going to be running around with a bit of a hack job for
the user database in the near future (either done by a student who needs
it in a hurry or done by one of the core devs to support a student who
needs it in a hurry) so while I don't like to design on the assumption
it's going to go wrong, I think in this case planning for a redesign
might be prudent because it's pretty clear we don't actually know all
our requirements.
Terri
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
