[Mailman-Developers] GSoC discussion

[Manish Gill]

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?