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

[Barry Warsaw]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120717/108aa580/attachment-0001.pgp>