Abhilash, Thanks for the summary.
Let me add a bit about what I think we should present in this interface. First, it should be RESTful and self documenting. The format of information delivered will be controlled by the http Accept: header The standard representation for communication between various modules of the MM system (core, user-manager,webUI, etc.) will be "application/hal+json" https://server.example.com/mailman/list/ABCDEFG/attribute/join_address returns the email address to which subscription requests should be sent. https://server.example.com/mailman/list/ABCDEFG/attributes https://server.example.com/mailman/attribute/posting_address/test_l...@example.com would return the URI representing the list https://server.example.com/mailman/attribute/posting_address/test_l...@example.com/attribute/join_address might return test_list-j...@example.com See https://gist.github.com/hjr3/2289546 (an E-commerce platform specification) to get a representative idea of the json formatting. I envision the simplified model to have the following core resources: user - A person address - An email address each address is owned by one person credential - An authentication binding associating a user with an identifier such as username/password, browserid, or oAuth list - A mailing list. Lists have attributes that apply to the list and also have a set of preferences which supplies defaults for subscription preferences subscription - the binding of an email address to a list. attributes - a dictionary of the parameters that characterize the list preferences - a dictionary of the parameters that apply to a subscription I am suggesting two primary differences from the MM core style of representation. First, rather than having multiple attributes and preferences as "columns" in a table, I would portray them as multiple rows in a table where the attribute names are a key that is used to select the corresponding value. Additionally, I would generalize the grouping of lists into a hierarchical tree that represents the enterprise organization rather than aspects of the internet namespace. By treating the preferences as a table of key-value pairs, we can easily extend the list of elements with plug-in modules without having to change the data handling or display mechanisms. Richard On Apr 26, 2013, at 7:00 PM, Abhilash Raj <raj.abhila...@gmail.com> wrote: > Hi all, > I wrote a brief summary[1] of this thread. Its in the form of notes sorted > according to participants and a small summary at the end( showing off > whatever I could understand reading the thread twice from head to toe ). > However I might have misunderstood ( or not understood at all ) or missed a > few things, forgive me for that. > > [1]: https://gist.github.com/maxking/5471211 > > Thanks, > Abhilash > > > On Sat, Apr 27, 2013 at 1:06 AM, Terri Oda <te...@zone12.com> wrote: > >> So... What have we decided? :) >> >> From my fuzzy "I read my email on a plane after delta woke me up at 3am to >> tell me my flight was cancelled" level of recollection.... >> >> The few things I we actually agreed on: >> >> - We like the idea of a rest interface. >> >> - That interface/API should probably be decided now and relatively >> permanently >> >> - then implementation details can be changed later as necessary (so it >> doesn't matter if we start with Django or whether mailman-user reads from >> mailman-core or vice versa, as long as it gets done and fulfills the >> promises of the API) >> >> - something something oauth something >> >> Can someone sketch out what that REST interface will look like as an >> actual architectural document that we can comment on? I don't care who >> does this; we just need somewhere to start, so any subscriber to this list >> can probably summarize the emails into a useful document. >> >> Terri >> >> >> >> ______________________________**_________________ >> Mailman-Developers mailing list >> Mailman-Developers@python.org >> http://mail.python.org/**mailman/listinfo/mailman-**developers<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/<http://www.mail-archive.com/mailman-developers%40python.org/> >> Unsubscribe: http://mail.python.org/**mailman/options/mailman-** >> developers/raj.abhilash1%**40gmail.com<http://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com> >> >> Security Policy: http://wiki.list.org/x/QIA9 >> > > > > -- > Abhilash Raj > _______________________________________________ > 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/rkw%40dataplex.net > > Security Policy: http://wiki.list.org/x/QIA9 _______________________________________________ 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
