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