2509
Comment:
|
3158
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
#pragma page-filename DEV/versions/7962704 | #pragma page-filename DEV/versions/14352690 |
Line 44: | Line 44: |
* There will be a fully privileged (i.e. unauthenticated) admin REST web service in the core. This will map many engine resources to URLs and allow for full programmable access to the engine model. This server will only listen on localhost and should never be exposed to the 'net. * There will be a proxy REST webservice that implements authentication and protects resources based on privilege. This can be exposed to the 'net and speaks to the admin REST server on the back end. It would allow some of the following use cases: * A user could programmatically change their subscriptions * A list owner could programmatically modify their mailing lists * A list moderator could programmatically clear their held messages * There will be a wsgi web user interface server, exposed on the 'net, which talks to the admin REST server on the back end. It provides an updated web user interface for interacting with Mailman. * Additional border servers can be implemented, e.g. providing NNTP or IMAP access to the message store. |
* There will be a fully privileged (i.e. unauthenticated) admin REST web service in the core. This will map many engine resources to URLs and allow for full programmable access to the engine model. This server will only listen on localhost and should never be exposed to the 'net. * There will be a proxy REST webservice that implements authentication and protects resources based on privilege. This can be exposed to the 'net and speaks to the admin REST server on the back end. It would allow some of the following use cases: * A user could programmatically change their subscriptions * A list owner could programmatically modify their mailing lists * A list moderator could programmatically clear their held messages * There will be a wsgi web user interface server, exposed on the 'net, which talks to the admin REST server on the back end. It provides an updated web user interface for interacting with Mailman. * Additional border servers can be implemented, e.g. providing NNTP or IMAP access to the message store. {{attachment:mm-architecture.png}} == Technologies == We will investigate the following technologies to implement bits of the above picture. * --([[https://launchpad.net/lazr.restful|lazr.restful]] to provide the admin REST interface)-- ('''updated 2011-04-04 barry: we are using [[http://ish.io/projects/show/restish|restish.io]] for the REST API layer in Mailman 3''') * [[http://pypi.python.org/pypi/Pylons|pylons]] and [[http://pypi.python.org/pypi/Genshi|genshi]] to implement the new user interface, with `lazr.restclient` to talk to the admin interface * [[http://pypi.python.org/pypi/Twisted|twisted]] to implement the NNTP and IMAP protocols |
PyCon Sprint 2009
I'm planning a one-day (at least) sprint for PyCon 2009, focused on Mailman 3 in general and on the REST server and UI in particular. This page is a placeholder for the moment, but I'll flesh this out as we get closer.
Attendees
Please add your name to the list below if you're planning to attend.
Name | Interests | |
Barry Warsaw | barry@list.org | Sprint chair |
Patrick Ben Koetter |
p@state-of-mind.de |
Sprinter |
Andreas Schosser |
a@state-of-mind.de |
Sprinter |
Florian Fuchs |
f@state-of-mind.de |
Sprinter |
Skip Montanaro | skip@pobox.com | Sprinter (Mailman/SpamBayes integration) |
Dates
Based on Patrick, Andreas, and Florian's availability, we will concentrate on sprinting on Tuesday, March 31st. It's possible we'll get some time on Wednesday and Thursday, but I (Barry) might have some other commitments and Thursday's a travel day.
Program
Progress Report
At the sprint we've made the following decisions and are beginning on tasks to achieve these.
- There will be a fully privileged (i.e. unauthenticated) admin REST web service in the core. This will map many engine resources to URLs and allow for full programmable access to the engine model. This server will only listen on localhost and should never be exposed to the 'net.
- There will be a proxy REST webservice that implements authentication and protects resources based on privilege. This can be exposed to the 'net and speaks to the admin REST server on the back end. It would allow some of the following use cases:
- A user could programmatically change their subscriptions
- A list owner could programmatically modify their mailing lists
- A list moderator could programmatically clear their held messages
- There will be a wsgi web user interface server, exposed on the 'net, which talks to the admin REST server on the back end. It provides an updated web user interface for interacting with Mailman.
Additional border servers can be implemented, e.g. providing NNTP or IMAP access to the message store.
Technologies
We will investigate the following technologies to implement bits of the above picture.
lazr.restful to provide the admin REST interface (updated 2011-04-04 barry: we are using restish.io for the REST API layer in Mailman 3)
pylons and genshi to implement the new user interface, with lazr.restclient to talk to the admin interface
twisted to implement the NNTP and IMAP protocols