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

[Richard Wackerbarth]

The problem in splitting data is that links between the various related entries need to be maintained.
This means having the ability to go from one entry to the related ones, and back again.
When the data is stored in multiple tables, foreign keys provide the link. When both tables reside in the same database, joins can be performed, etc. However, when the tables are in separate databases, at a minimum, each database needs to "know about" (store the inverse key) the other entries. They also need to be able to assure that the corresponding entries in the foreign tables get created, and likely require that they be unique. Because of thread locking considerations, this may not be so easy to accomplish.

On Jul 11, 2012, at 10:07 AM, Florian Fuchs wrote:

> 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
>> 
> 
> _______________________________________________
> 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/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9