[Mailman-Developers] Login / User Identification Issues in MM3

[Florian Fuchs]

Hi there,

Am 11.07.12 15:34, schrieb Richard Wackerbarth:
> On Jul 11, 2012, at 8:14 AM, Stephen J. Turnbull wrote:
>> Richard Wackerbarth writes:
>>
>>> What I am advocating is that the "core" message handler NOT be the
>>> keeper of ONLY PART of it.
>>
>> What I'm advocating (mildly, because somebody else is going to have to
>> do the work) is that the core be the keeper of ALL of it.  The core is
>> not just a "message handler".  It is also a database, containing both
>> list information and subscriber information.  

If we're only talking authentication data, I agree.

But I also agree with Terri that there might be a good amount of user
data used by Postorius, Hyperkitty or any other web ui/client that just
doesn't have anything to do with mailman's core tasks. And I don't see
why something like "preferred ui theme" or profile-related stuff like
"irc nick" should be stored in the core db.

Isn't it very common that applications combine information from
different sources (databases, webservices,...) in one place (with or
without caching them locally)? I don't see anything unusual in the
concept of having some mailman-related user data managed by the mailman
core and other kinds of data handled by the
database/file-structure/key-value-store/web-service(s) that a web
application is using.

If Postorius and HyperKitty decide to share some information in one
place, because the projects are so closely related, that's of course a
fine idea. But I wouldn't try to cram everything into the core db just
for the sake of having it all in one place.

Florian


> 
> OK, so we agree that ALL of the information SHOULD be stored in one place.
> That means that this database will need a lot more information, such as access control specifications, etc.
> Further, it needs to be extensible so that various users can add whatever customizations and extensions they need.
> 
> And each of those functions will need supporting views, etc.
> 
> Pretty soon, you will find that what you need approaches something that already exists -- a relational database.
> Rather than "reinventing the wheel", we should just use an already existing database system and make all of the data directly accessible.
> 
>> Since a minimum of subscriber information is absolutely essential to the core job, all of
>> it may as well be in there.
> 
> This does not follow logically.  Since only a minimum of information is essential to the core job, it may well be more appropriate for it to get that information from another source as needed.
> 
>> In some configurations we will want the subscribers to be authenticated, so we may as well keep all such
>> information in the core's database.
>>
>> Steve
> 
> Applying your previous argument, I could equally say "since the web user needs to be authenticated, we may as well keep all such information in the webUI's database"
> 
> Richard
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at 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/f%40state-of-mind.de
> 
> Security Policy: http://wiki.list.org/x/QIA9
>