#######################################################################
exhibit 1:
The REST API provides
GET /lists/{list_identifier}/config
PUT /lists/{list_identifier}/config
PATCH /lists/{list_identifier}/config
This allows reading of all list config variables (see bottom of this message
for which ones). It also allows for setting of any individual config variable.
#######################################################################
exhibit 2:
The REST API also provides
GET /lists/{list_identifier}/config/{config_variable}
PATCH /lists/{list_identifier}/config/{config_variable}
Which allows any individual config variable to be read and modified.
#######################################################################
Effectively exhibit2 completely duplicates exhibit1 for no substantial gain.
exhibit2 significantly increases the complexity of the overall system due to
its fine grained duplication of everything in exhibit1. Right now I’m facing
write a bunch of code to handle the fine grained config variable setting, all
the while thinking “but this is all duplicate functionality”.
I’m wondering if anyone would miss exhibit 2 if it was deleted from the REST
API, saving on testing and complexity but losing nothing.
Have I missed something? MAYBE its possible that different config items might
have different user access requirements, justifying fine grained control,
however I can’t see how right now.
Thoughts?
... dict(
... acceptable_aliases=['o...@example.com', 't...@example.com'],
... admin_immed_notify=False,
... admin_notify_mchanges=True,
... administrivia=False,
... advertised=False,
... anonymous_list=True,
... archive_policy='never',
... autorespond_owner='respond_and_discard',
... autorespond_postings='respond_and_continue',
... autorespond_requests='respond_and_discard',
... autoresponse_grace_period='45d',
... autoresponse_owner_text='the owner',
... autoresponse_postings_text='the mailing list',
... autoresponse_request_text='the robot',
... display_name='Fnords',
... description='This is my mailing list',
... include_rfc2369_headers=False,
... allow_list_posts=False,
... digest_size_threshold=10.5,
... posting_pipeline='virgin',
... filter_content=True,
... first_strip_reply_to=True,
... convert_html_to_plaintext=True,
... collapse_alternatives=False,
... reply_goes_to_list='point_to_list',
... reply_to_address='b...@example.com',
... send_welcome_message=False,
... subject_prefix='[ant]',
... welcome_message_uri='mailman:///welcome.txt',
... default_member_action='hold',
... default_nonmember_action='discard',
... )
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
