Hey guys. This is in response to Richard's email for project discussions.
Richard and I have been having discussion regarding how to proceed with the project and he has been very helpful in getting me started with the project.
Right now, I'm focusing on the internal data representation of various
Resources in the system and how they might translate on an API level.
So, for
example, in trying to expose MailingList objects, as of now, there is
no way to
post messages to a list externally. 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.
Here is a summary of what we discussed :
Discussion regarding data flow: 1. Where is the data for various sources coming from? Where is it going? 2. Where should we provide hooks to extend/modify or perform any number of required operations on that data? 3. What operations should we provide on what type of data?
As an example, starting with List and Member resources, as they are now represented in Postorius:
List Resources
Current Operations on individual lists. - Subscription/Unsubscription - Addition/deletion of various roles in a list, like owner, moderator. - Message moderation (accept, defer, discard, reject) - .settings for various list settings to control the list preferences.
What will be useful to have:
Methods to provide filtering based on various criteria.
Member Resources
Members are Subscribers to public or non-public lists. As of now, they don't have much anything they can do.
- Methods that allow posting of messages. As Wacky noted, User has no need to concern herself how it might be done (could be RESTful, could simply be an internal Email object sent over to the -core)
- The API only exposes owners and moderator email addresses. You can't DO anything with them yet. (Say, an owner needs to post an announcement via the API - how might we achieve that via the REST Interface?)
Moderators and Owners don't stricly have a 'model' in the API. How might exposing their functionality make sense?
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.
Similarly, conceptual models for other resources that should be exposed, and how might they be used by clients should be made/extended.
Thoughts? Comments?
On 05/07/2013 10:18 PM, Manish Gill wrote:
Hey guys. This is in response to Richard's email for project discussions.
Richard and I have been having discussion regarding how to proceed with the project and he has been very helpful in getting me started with the project.
Right now, I'm focusing on the internal data representation of various Resources in the system and how they might translate on an API level. So, for example, in trying to expose
MailingListobjects, as of now, there is no way to post messages to a list externally. 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.Here is a summary of what we discussed :
Discussion regarding data flow: 1. Where is the data for various sources coming from? Where is it going? 2. Where should we provide hooks to extend/modify or perform any number of required operations on that data? 3. What operations should we provide on what type of data?
As an example, starting with List and Member resources, as they are now represented in Postorius:
List Resources
Current Operations on individual lists. - Subscription/Unsubscription - Addition/deletion of various roles in a list, like owner, moderator. - Message moderation (accept, defer, discard, reject) - .settings for various list settings to control the list preferences.
What will be useful to have:
Methods to provide filtering based on various criteria.
Member Resources
Members are Subscribers to public or non-public lists. As of now, they don't have much anything they can do.
- Methods that allow posting of messages. As Wacky noted, User hasno need to concern herself how it might be done (could be RESTful, could simply be an internal Email object sent over to the -core)
- The API only exposes owners and moderator email addresses. Youcan't DO anything with them yet. (Say, an owner needs to post an announcement via the API - how might we achieve that via the REST Interface?)
Moderators and Owners don't stricly have a 'model' in the API. How might exposing their functionality make sense?
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.
Similarly, conceptual models for other resources that should be exposed, and how might they be used by clients should be made/extended.
Thoughts? Comments?
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/mgill25%40outlook....
Security Policy: http://wiki.list.org/x/QIA9
I should mention that this is for the REST API for Postorius/Django project.
Manish Gill writes:
So, for example, in trying to expose
MailingListobjects, 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?
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.
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
MailingListobjects, 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.
Richard Wackerbarth writes:
I appears that my communication was not as successful as I had hoped.
I don't know about your communication. My point here is that the *student's* communication was insufficient.
Posts to the list involve people who are not party to the conversion on IRC and vice versa. Details like the object of "filter" need to be included. "Look at" may be an obvious indication of "we're talking about presentation" in context of a conversation, but it's not enough in a post that summarizes that conversation to those not present.
As I wrote earlier, my criticisms are going to be severe, even harsh. There's a good reason for that. What we're doing here is quite different from most uses of mailing lists, which are either much more casual (conversational correspondence) or involve a group whose members are all more or less up to speed on the content.
That's not going to be the case here. Important decision-makers (Terri and Barry) are currently not in the loop. The students are going to be very much focused on their own proposals, and will take time to get up to speed on others'. Posts need to avoid presuming very much knowledge on the part of other subscribers, at least early in threads.
There's another important point that hasn't been mentioned yet. You GSoC students are Mailman developers now. It's not about your proposal, it's about the Mailman project. Your proposal is important to us in the context of the project, not standing alone by itself. You should help support the other students in their projects, too. You may not have anything constructive to contribute to others' tasks yet, but you *should* be able to ask questions about them. That's important for learning about how Mailman works overall.
On 05/08/2013 10:39 AM, Stephen J. Turnbull wrote:
Richard Wackerbarth writes:
I appears that my communication was not as successful as I had hoped.
I don't know about your communication. My point here is that the *student's* communication was insufficient. I'll be more thorough in the future. As I wrote earlier, my criticisms are going to be severe, even harsh. There's a good reason for that. What we're doing here is quite different from most uses of mailing lists, which are either much more casual (conversational correspondence) or involve a group whose members are all more or less up to speed on the content. You can be critical without being harsh. That's not going to be the case here. Important decision-makers (Terri and Barry) are currently not in the loop. The students are going to be very much focused on their own proposals, and will take time to get up to speed on others'. Posts need to avoid presuming very much knowledge on the part of other subscribers, at least early in threads.
There's another important point that hasn't been mentioned yet. You GSoC students are Mailman developers now. It's not about your proposal, it's about the Mailman project. Fair enough. Your proposal is important to us in the context of the project, not standing alone by itself. You should help support the other students in their projects, too. You may not have anything constructive to contribute to others' tasks yet, but you *should* be able to ask questions about them. That's important for learning about how Mailman works overall.
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/mgill25%40outlook....
Security Policy: http://wiki.list.org/x/QIA9
2013/5/7 Manish Gill <mgill25@outlook.com>:
Hey guys. This is in response to Richard's email for project discussions.
Richard and I have been having discussion regarding how to proceed with the project and he has been very helpful in getting me started with the project.
Right now, I'm focusing on the internal data representation of various Resources in the system and how they might translate on an API level. So, for example, in trying to expose
MailingListobjects, as of now, there is no way to post messages to a list externally.
I don't know if posting messages through the API is a priority. I'd suggest to start with the more fundamental functionality, like creating domains/lists, list configuration, subscribing and unsubscribing, adding owners and moderators, moderating subscriptions and messages.
Regarding owners and moderators: It's true that the core's REST API does not expose them as single models, but as membership records with a 'role' attribute. Postorius reflects the same role system (admin/owner, moderator, member) that is currently implemented in the core (which is also kind of well known from Mailman2).
In Postorius, the permissions that are granted to each of these roles are static, for example a moderator can moderate messages as well as subscription requests, but it's currently not possible to create groups of moderators that can only moderate messages *or* subscriptions. In theory it would be possible to ignore the roles given by the core and grant more fine-grained permissions to separate groups or users. But (at least for now) Postorius does not do that for various reasons.
There has been some discussion on IRC and elsewhere if the public API should be implemented as part of Postorius (as the project title on the ideas page says) or as separate app. My personal opinion is that I don't have a problem with any of the two options. But I *do* think that if we provide an "official" admin web ui and and "official" public facing REST API, both of them should reflect the role system reflected in the core and both should have the same authorization logic -- meaning: A list owner/moderator/member in Postorius should be allowed the same things as a list owner accessing the public REST API.
Florian
On May 07, 2013, at 06:58 PM, Richard Wackerbarth wrote:
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.
This is definitely aligned with how I see an authenticated (i.e. public) REST API working. The private/admin API gives you everything, while the public one would only provide you the limited subset of things you're allowed to do.
Or put it another way, the private API doesn't know who you are[1] so it can't limit your access. The public API does know who you are, and so it must only present to you the resources and actions that you're authenticated for.
-Barry
[1] Except in the sense that you're essentially root to the Mailman core.
participants (5)
-
Barry Warsaw -
Florian Fuchs -
Manish Gill -
Richard Wackerbarth -
Stephen J. Turnbull