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

[Barry Warsaw]

On Jul 13, 2012, at 11:57 AM, Stephen J. Turnbull wrote:

>Barry Warsaw writes:
>
> > I don't see any reason why it couldn't be mapped to a REST API; it's just a
> > lack of need, and nobody's written it yet.  The question is whether
> > IUserManager is actually the right API for a REST interface - in general I
> > don't think you need a 1-to-1 mapping of internal model or APIs to REST.
>
>My suspicion is that in particular (ie, when addressing a specific set
>of requirements) you don't need a 1-1 map of internal APIs to REST.

I agree.

>But if you want World Domination (and you have expressed that ambition on
>occasion), you need a system that grows new complex functionality
>organically.  That, I think, means that we want various parts of the system
>to cooperatively build a single database that is offered to all components.
>
>If you want to say, OK, I'm not really serious about that, that's fine by me:
>we *need* a killer MLM, and Mailman 2 isn't it (any more).  But if you want
>to try for World Domination, I think the database (ie, the "social network
>engine") is the one component that's going to make or break that enterprise.

I don't necessarily disagree with any of that, but that doesn't necessarily
mean that the API exposed by the core needs to provide that database.  OTOH, a
separate user database component certainly could expose that stuff, and where
the two systems overlap in their support for the uber-model, certainly the
resource locations and semantics should be as close as possible.

As an example, the core currently exposes just a few attributes at the user
resource in REST: user_id, created_on, password (optional), and display_name
(optional).  These live at <baseurl>/users/<userid>.  If the separate user
database also kept track of things like Facebook and Twitter ids, these would
also be available at the same location (different base-url of course) and the
returned JSON would just contain additional entries for that extra data.

> > We've just planned ahead and made the relationship between members
> > and the mailing lists based on the fqdn_listname of the mailing
> > list[*].
>
>This should be the List-Id.  RFC 2919 essentially says that the
>mapping of "mailing lists" (whatever *they* "really" are) to List-Ids
>is 1-1 by definition.  I think that in practice this is probably going
>to work well, in the sense that people who thoughtlessly initialize a
>new List-Id when they migrate domains probably don't think (much)
>about the fact that it's a new list, while people who take the care to
>keep the same List-Id surely do care about the list's identity.

LP: #1024509

> > zope.interfaces, just that we have to be able to implement the
> > methods and properties defined in these interfaces using REST
> > calls.
> > 
> > Probably a good start would be:
> > 
> >  * IAddress
> >  * IMember
> >  * IRegistrar
> >  * IRoster
> >  * ISubscriptionService
> >  * IUser
> >  * IUserManager
>
>This list kind of worries me -- it's very specific and fragmented.  Is
>there a higher-level way of doing this mapping?

There's not unfortunately.

> > [**] Hey Florian, continuing on a theme, maybe "Vicious".  Get it? :)
>
>I see ....

I think we'll have to start calling the core engine "Lee", since as we all
know, it should be the center of attention. :)

-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/3db7a8e4/attachment.pgp>