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

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > I think that you are finally beginning to understand the
 > perspective that I am trying to provide.

I don't have any trouble understanding the perspective you're trying
to provide in the abstract; it's just Software Systems Design 301.

What I have trouble seeing is why you want to go to this level of
abstraction for Mailman 3, and what implications is has for design and
implementation of Mailman services.

 > Yes, to implement anything, we will need the concrete descriptions
 > at the protocol level.

But AIUI, REST isn't a concrete description.  Wikipedia, for example,
calls it an "architectural style".  Specifically, that article defines
it as a service meeting 5 constraints (and there's an optional 6th).[1]
If your abstract service doesn't satisfy those constraints, then it
can't be implemented RESTfully, which in turn constrains implementer
designs (eg, it means changing multiple modules to implement a new
service).

So for this purpose, I see the HTTP verbs used in REST, such as GET,
as being primitives obeying certain constraints, but not as
necessarily implemented by trivial references to the concrete HTTP
implementation.  Similarly, the REST approach to addressing resources
via URLs puts some constraints on the structure of Mailman's data.
IOW, REST is a language for describing interactions among Mailman
components, not a specific implementation of such interactions.

 > Specifically, one interface may provide multiple implementations
 > which accomplish the same system service. (Many ways to skin the
 > cat) Alternate implementations are required to provide just one of
 > them.

I don't understand.  How is one component that speaks REST supposed to
communicate with another specified in terms of the ZCA?  They satisfy
different constraints.

Footnotes: 
[1]  http://en.wikipedia.org/wiki/REST