On Jul 11, 2012, at 12:50 PM, Stephen J. Turnbull wrote: > Richard Wackerbarth writes: > >> 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. > > We're already doing that, with ORMs overlying the RDBMS.
No! Although you are making available (some/most/all) of the data values, you are not making available the ability to make arbitrary SQL-type queries to view the data. >> 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. > > True, but we've already agreed that the user information should be > kept in one place, based on your experience. > >> 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" > > It's not the same argument. A mailing list needs a message > distribution agent; it doesn't *need* a webUI. In this day and age, try selling that one! Only those of us, and that especially includes me, who were around "way back when", before http even existed, know any other way. :) Additionally, look at what other MM developers are doing. For example, Hyperkitty is not oriented to retrieving archived messages by email. I think we MUST assume that there will be a web interface. If someone wants to have a mailing list without one, it should be easy enough to "stub off" the limited amount of user information that is needed. But I think that this use case will be the exception rather than the rule. > There may be implementation reasons why it's better to handle database > requirements in the webUI or a new daemon, but nobody's given any yet. As far as the complexity of access is concerned, the mail handler probably has the lowest requirements. The present architecture would have to be extended significantly to provide for appropriate handling of ALL of the data. That includes a much richer query capability. Presently, the message handling is integrally tied to the database implementation. Customization extensions will intrude into parts of the system which they should not affect. As far as I am concerned, those are more than adequate reasons. I view your argument as the message handler claiming "I'm special! Everyone else has do do things my way. I get special privileges." -- IMHO, the tail is wagging the dog. Let's split shared data storage from the message handler, and from any "admin-by-mail" component, treating each of them as separate logical components. Provide each of them EXACTLY the same accesses as those provided to the WebUI, Message Archiver, etc. _______________________________________________ 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
