Stephen, >From this posting to which I am replying and other recent ones from Barry, >etc. I conclude that it is highly likely that the three of us have somewhat >similar conceptual models of an extensible MM system. However, because of the >terms that we have chosen in our descriptions, we have failed to communicate. >As a result, we have misinterpreted the others' descriptions.
For example, in earlier postings, I used the term "component". Rather than the characteristics that Stephen seemed to apply to the term, my intended concept is one which, in the text quoted, I would now call a "service" -- a "user service" for information related to the persons participating in the lists, a "post routing and delivery service" that interfaces with the MTA, an "admin handling service" for changing the state of the stored choices, etc. (My exact grouping of functionality may not be correct. But that is a separate issue.) Now, when it comes to interfaces, in that context, I have been referring to "service interfaces". Barry has acknowledged that the (IUser, et al.) zope interfaces are, collectively, an implementation-level interface which, presumedly, provides capability sufficient to implement the portion of the service-level interfaces that are required by the "core" modules provided. They may also provide some additional functionality that someone anticipated to be of use by other services which might wish to interact with these interfaced objects. Similarly, I now believe that Stephen's use of "core database" was more a reference to the union of all of these service-level interfaces rather than that of the interpretation which I had placed on the term, namely a "persistent store running in conjunction with the post routing service" Now, hopefully, we can agree that it is necessary to have a "user service". Further it is reasonable to attempt to have this service distinct from the "post routing service". The question is then "How will these services interface to each other?" Stephen says: > ... having a single interface (with perhaps a REST "binding" for IPC and a > direct > zope.interfaces binding for within-process use) I agree with the "single interface" aspect of it, particularly if that interface is viewed at the functional level rather than at an implementation level. However, I feel that there should be a complete REST binding for that functional interface. This interface can then be implemented by a zope.interface, and/or in any other format appropriate for the implementing code. However, the implementation interface must not provide any inter-service capability that is not reflected in the "interface". Intra-service capabilities are quite useful, particularly when they provide alternate functional signatures which accept local proxies for interacting objects. Further, as an inter-service design constraint, it should be assumed that the implementation of any service might be "remote" and accessible only by way of the REST interface to it. In addition it should be assumed that the implementation of that service will be in an arbitrary programming language other than python. Designs which violate either of these assumptions should not be accepted because they reduce the ductility of the interface. The implementation interfaces provide only a proxy for the conceptual objects defined in the service interface and any action on those proxies needs to be conveyed to the conceptual object by means of an access specified in the system interface. Richard On Jul 12, 2012, at 10:03 PM, Stephen J. Turnbull wrote: > Barry Warsaw writes: > >> The question is whether we want to support running the core without >> having this user service available, i.e. in standalone mode. Are >> we going to require that this service be running in order to run >> the core? I think we shouldn't be so strict. > > But *some* user service needs to be available. This is to my mind a > core component of Mailman in any case. I don't see why having a > single interface (with perhaps a REST "binding" for IPC and a direct > zope.interfaces binding for within-process use) and a default > implementation of that service as a core component (but separate from > the post routing and delivery and admin routing and handling services) > would be very costly in implementation and maintenance, but it ensures > the flexibility to deal with unknown future requirements everybody > says is important. _______________________________________________ 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
