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?