Removal of REST API method /lists/{list_identifier}/config/{sub_resource}

####################################################################### 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@example.com', 'two@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@example.com', ... send_welcome_message=False, ... subject_prefix='[ant]', ... welcome_message_uri='mailman:///welcome.txt', ... default_member_action='hold', ... default_nonmember_action='discard', ... )

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@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@example.com', 'two@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@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/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9

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@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@example.com', 'two@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@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/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
participants (1)
-
Andrew Stuart