I think I would second the idea of having a single component/database
that is responsible for the management of user information.
Am 12.08.2015 um 16:23 schrieb Barry Warsaw:
The other components are in a pullrelationship with core,
Is this mechanism of pulling user information from the
I think I would second the idea of having a single component/database that is
responsible for the management of user information.
The problem is that the larger Mailman ecosystem is designed to be a loose
collection of components so there is no way to define what information each
component
Having said all that, one thing that might work is for the Mailman Core to
provide the ability to retrieve key/value pairs that can be attached to any
given resource. This is sufficiently simple to mean it would present no
problems for forward compatibility.
key/value pairs would suffice for
Andrew Stuart writes:
So there is something to be said for a very simple Mailman Core
key/value store mechanism that would meet some simple needs. The
argument against this is “well you’re going to outgrow it pretty
quick anyway so why not immediately start with a more full featured
On Aug 12, 2015, at 10:28 AM, Stephen J. Turnbull wrote:
The big problem is that as Simon points out we no longer have a truly
centralized database. Each component now keeps user information
related to itself, but it's not communicated across the components
very well.
This is true, and it bites
Barry Warsaw writes:
One of the things I think we need is better holistic documentation which
describes how to use the integrated system,
The big problem is that as Simon points out we no longer have a truly
centralized database. Each component now keeps user information
related to itself,
On Aug 11, 2015, at 05:43 PM, Simon Fromme wrote:
2. Is there a timeframe in which a good Mailman 3 documentation can be
expected? I find it quite hard to solve problems myself given the small
amount of informationon the web right now.
One of the things I think we need is better holistic
