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