[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

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_list@example.com would return the URI representing the list

https://server.example.com/mailman/attribute/posting_address/test_list@example.com/attribute/join_address might return test_list-join at 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.abhilash1 at 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 <terri at 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 at 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 at 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