On May 7, 2013, at 1:13 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Manish Gill writes:
So, for example, in trying to expose
MailingList
objects, as of now, there is no way to post messages to a list externally.Out of scope. You could do something that would allow a quick, urgent message to be posted, but you are very likely to embarrass yourself, and us. Eg, http://code.google.com/p/soc/issues/detail?id=1843. :-)
Similarly, something to extend the Member model so that privileges make sense on an API level - with Owners and Moderators being able to perform certain actions that are not exposed to regular members, etc.
I think Wacky would disagree with that strategy. Extending the member model is not a maintainable strategy. There are several alternatives that are more extensible.
What will be useful to have:
- Methods to provide filtering based on various criteria.
Filter what?
I was comparing what a consumer of the Postorius interface might like to see that is not just a proxy forwarding the MM-core interface.
As an example, rather than all of the lists, just those lists for which the represented user is the administrator. If the interface is not going to provide full SQL query capability, it can still provide some portion of the selection filtering.
Wacky: 1. One way to look at moderators is that it is nothing more than another mailing list (with different policies about subscribing, etc.) 2. Another way is to consider it to be an additional roster of a different class of subscribers. 3. Another way is to treat each subscription as having one or more roles.
Another way is ACLs on resources.
Here I was speaking of ways that an installation might present the information -- trying to show that the "storage model", whatever it happens to be, might not be the view that the implementor wishes to display.
I appears that my communication was not as successful as I had hoped.