Hi,
On Tuesday, February 21, 2012 02:28 CET, Barry Warsaw wrote:
> Even if we came up with a way
> to extend the core schema and store the data in the core, how would you access
> it? There would probably have to be a generic REST API for getting key/value
> data associated with the user in a
Hi,
On Tuesday, February 21, 2012 14:59 CET, Richard Wackerbarth
wrote:
> The database access becomes a stack. The UI always accesses its data through
> its model. The implementation of the access could be directly as a table on a
> local database (as django is normally used) or it could u
On Wednesday, February 22, 2012 07:49 CET, "Stephen J. Turnbull"
wrote:
> Florian Fuchs writes:
>
> > Agreed. Django's User model most definitely covers all our
> > needs.
>
> What version of Django's User model are you using? The vanilla User
> is actually rather limited. Or do you me
On Feb 23, 2012, at 4:46 PM, Florian Fuchs wrote:
>>> Of course, if we implement such a custom backend we should do it in a
>>> generic and reusable way. I just think making a full-blown django app for
>>> what is usually just a .py file might be a bit overkill... But as I said:
>>> debatable..
On Feb 23, 2012, at 11:46 PM, Florian Fuchs wrote:
>Yep. But we need to decide how tolerant we are when it comes to
>inconsistencies between the state of the core data and a web ui session. A
>list of mailing lists might be stored on a per session basis - if a new list
>is created by a third party
On Feb 23, 2012, at 11:04 PM, Florian Fuchs wrote:
>> Even if we came up with a way to extend the core schema and store the data
>> in the core, how would you access it? There would probably have to be a
>> generic REST API for getting key/value data associated with the user in and
>> out of the
On Feb 22, 2012, at 03:49 PM, Stephen J. Turnbull wrote:
>We do, I think. I think the core DB should be constant across
>Mailman installations, and restricted to fields useful in "forum"
>administration (ie, not restricted to mailing lists, although that
>will be the main purpose of Mailman 3 at
On Feb 23, 2012, at 5:43 PM, Barry Warsaw wrote:
> The counter argument is that the core's database should only contain the data
> that is needed to do its function.
Yet another argument would be:
The MM suite can be partitioned logically into a message handler, an archiver,
an administration-by-
