In many respects I think that we are in agreement. If I understand you, we both envision a distributed database whereby any of the components might actually provide the data storage for some specific class of information. For example, without specifying where in the system it will reside, there is a "UserManager" that maintains information about the users. It would also be responsible for registering ALL user instances and providing lists of users that meet certain constraints. In addition, it provides an access mechanism for properties associated with particular users.
However, I think that we differ in terms of the public interface specifications. The specification that you suggest produces a particular python object. The specification that I suggest contains only those characteristics which are exposed on the REST interface. It does not specify the exact format in which those characteristics are presented, but only what characteristics are available and what operations can be performed. In this form, no component external to the UserManager is permitted to rely on any aspect of the representation which falls outside of the available public characteristics. The place where I am unclear of your intentions concerns this python object. In theory, it may have characteristics that are not exposed to the REST interface. Do you permit your functional modules, (the message handler or the administration interface, for example) to rely on any characteristics that are not properly exposed by the REST interface. If so, why? On Jul 12, 2012, at 10:07 AM, Barry Warsaw wrote: >> I think that this is the wrong approach to the extent that "core", and here, >> by "core" I think you mean the "admin-by-mail" component, does anything other >> than call the same REST interface that the web UI would use. > > It could, though internally, that would be hidden behind the implementation of > IUserManager, IUser, and associated objects. We're saying the same thing but > in a different way. The advantage of hiding this behind the zope.interfaces > is that we can have multiple alternative implementations of those interfaces, > so that whether it's REST or a SQL call doesn't matter to most of the core. >>> So for example, an IMember associates an >>> IAddress with an IMailingList. The standard implementation of that doesn't >>> use a foreign key between the `member` table and the `mailinglist` table. >>> Instead it uses the fqdn_listname, i.e. a string. >> >> I don't agree. Your string which contains the fqdn_listname IS a foreign key >> to the mailinglist table. It may not be the primary key in some >> installations, but it is one-to-one with that key and could be used directly >> as the primary key. > > The point is that it's not a foreign key constraint in the members table. OK, I think we are in agreement WRT this concept. You seem to have taken "foreign key" to imply a specific implementation of the concept to which I was referring, namely some key which designates a unique instance in the referenced table. > Doing that would, I think, prevent you from putting the mailinglist table in > one database and the member table in another. It makes the associated queries > less efficient, but provides for a useful measure of flexibility. Were this not Python, but C++, I would suggest that we consider offering multiple signatures for the exposed functionality. For example, it the function were to deliver a list of MLs to which an Address is subscribed, the address might be provided as a string (the email address in canonical form), the pk of the entry in the underlying Address database, or as an object of the Address class. Although the same could be done in python through introspection, or similar techniques, I don't know to what extent doing so would introduce inefficiencies. > P.S. FWIW, I think this separate "user database" component with REST calls in > the IUserManager (et al) implementation would not actually be difficult to > mock up. I don't have the time to do the coding, but would be happy to > discuss details if someone wanted to take a crack at it. I definitely will take a crack at it since I suspect that doing so would allow Postorius to have all of its user information handled in one place and still provide the "admin by mail" to work with its restricted expectations. _______________________________________________ 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
