On Jul 13, 2012, at 07:34 PM, Richard Wackerbarth wrote: >I think that you have missed a level of abstraction.
I guess it's "turtles all the way down" :) >The service, per se, does not REQUIRE a REST interface in order to operate. >It only requires an implementation (in any language) and mutually agreed >intra-service bindings in a mutually acceptable language. I think my vision of the architectural organization is very similar to Stephen's, and we only need the abstractions at a particular level to describe how other components at that same level will interoperate. Within the core engine, which is all one self contained Python application (logically, if not actually, a single address space), then I think zope.interfaces and the Zope Component Architecture are as abstract as we need to get. If a component within the core, say the bounce detector, needs information about mailing lists, then it uses the ZCA abstractions to get Python objects (which may contain concrete implementation, or simply be proxies) which provide the services promised by those interfaces. I don't see any value in getting any more abstract than that, within the core, at least not right now. As we talk about separating out components into separate processes, possibly residing on different machines, then the ZCA isn't an appropriate abstraction. We're really talking about IPC here, and while there is no end to IPC protocols, it seems to me that HTTP/REST is a good one to choose, because it's built on fundamental, well-supported protocols, is easy to understand, document, and implement, and is discoverable. I'll note though that there's no reason why other IPC protocols couldn't be added later. An important implementation principle with the mm3 core, based on my experiences with its violation in mm2, is that the REST implementation contains no functional logic. All it does is translate input from HTTP into Python objects on the way in, and Python objects to HTTP on the way out. This principle is replicated by the shell scripts and the email commands, which actually, are alternative parallel forms of IPC into the core. So if someone wanted to add XMLRPC, CORBA, or whatever new protocol all the kids are using next year, it can be done probably with the same ease at which REST support was added. Also, these abstraction layers are not mutually exclusive. Internally, the core could use the ZCA abstraction to get a proxy to a user object which communicates to the user manager over LDAP and the core wouldn't blink an eye. >Because we have chosen a RESTful mechanism as a communications medium for >services hosted on separate processors, we will need a REST interface >specification. But, that REST interface is only one implementation of the >service interface. The REST particulars are not really a part of the service. I see what you're saying, and this 1000ft abstraction of the service may be useful in the sense that it's documentation for anyone else wanting to implement said service using a different IPC mechanism, but right now where the project is, this is a bit too abstract to be meaningful *to me*. I have no problem with this kind of service description being defined before the user manager service is implemented, but it still has to be made more concrete one level down into an IPC protocol definition before it can be useful. Cheers, -Barry
signature.asc
Description: PGP signature
_______________________________________________ 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
