[Mailman-Developers] Removal of REST API method /lists/{list_identifier}/config/{sub_resource}

[Andrew Stuart]

Alternatively I could just ignore these methods and not put them in the proxy although that grates against my sense of completion …   :-)

as

On 19 Feb 2015, at 7:51 am, Andrew Stuart <andrew.stuart at supercoders.com.au> wrote:


#######################################################################
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=['one at example.com', 'two at 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='bee at 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 at 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/andrew.stuart%40supercoders.com.au

Security Policy: http://wiki.list.org/x/QIA9