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

[Barry Warsaw]

On Jul 13, 2012, at 11:56 AM, Richard Wackerbarth wrote:

>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?"

I think we're definitely converging on a common language for all the moving
parts.

>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.

WADL is, afaik, the definition language for RESTful web services:

http://en.wikipedia.org/wiki/Web_Application_Description_Language

It is an XML-based format.

Some REST implementation libraries provide a way to generate the WADL from the
code, but frankly the ones I've used have enough downsides to far outweigh
automatic WADL generation.  I'm not aware of anything that takes WADL as the
input and creates the REST implementation for you, so all things considered, I
think WADL is fairly useless to us.

I would be happy enough with human readable <wink> documentation that
described this user service in terms of resource locations and contents.
Although it's been years since I read it, Leonard Richardson's definitive
O'Reilly book RESTful Web Services talks about how this description can even
(or maybe *should*) be HTML, with links to the actual resources being
described.

Or thought about it a different way, mm3's REST API only supports JSON
representation for resources.  You could implement a parallel representation
using HTML that included these descriptions.  I bet you could even do this in
Sphinx in a very human-friendly format, with "base-url" templating so that the
resource locations are resolvable wherever the user service is deployed.

Note that this service can have varying levels of compatibility.  E.g. we
could say that level 1 is required, and define this as the minimal service
required by the core.  Things like Facebook id would not be in level 1.
Higher levels would provide additional information that could be used to
enhance the user experience.  I have no idea whether more than two levels is
necessary, but I do think there needs to be some discussion of extensibility.

>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.

I think the use of the term "proxy" is informative here.

Let's say the core only cares about level 1 user service compliance.  Maybe
that's implemented as an external (to the core) service.  In this case, the
implementation of interfaces like IUser and IUserManager would simply be
proxies to this service.  The service itself doesn't care about these
zope.interfaces, it only cares about providing a level 1 compatible user
service via REST (probably with a JSON representation).

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/20120713/57b542c3/attachment-0001.pgp>