PyCon 2009 sprint: Webinterface
Barry,
I am collecting information for my work on the MM3 Webinterface while we meet at PyCon 2009 sprint.
So far I have found the "Summer of Code summary" <http://wiki.list.org/display/DEV/2006/08/20/Summer+of+Code+summary>.
Any other information/writing I should collect and read before we meet?
I also believe I had seen a page where you (?) had noted a link for a design you favoured, but I can't find it. Can you post the link or come up with a list of sites you like? (Not that we weren't able to develop design. I just want to get an idea.).
Thanks,
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Patrick Koetter Tel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de
Amtsgericht München Partnerschaftsregister PR 563
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 23, 2009, at 10:20 AM, Patrick Ben Koetter wrote:
I am collecting information for my work on the MM3 Webinterface
while we meet at PyCon 2009 sprint.
Which I'm really looking forward to! Apologies for not responding
sooner.
So far I have found the "Summer of Code summary" <http://wiki.list.org/display/DEV/2006/08/20/Summer+of+Code+summary>.
Any other information/writing I should collect and read before we
meet?
The only other thing to look at is this branch:
https://code.edge.launchpad.net/~mk2s/mailman/restserver
It's the work that Maki and Andrew did at last year's sprint. This is
for the Mailman 2.2 branch, but there's some interesting work there
regarding the REST server. I don't know if we should use this branch
in the 3.0 version, but it's worth discussing as a starting point.
I also believe I had seen a page where you (?) had noted a link for
a design you favoured, but I can't find it. Can you post the link or come up
with a list of sites you like? (Not that we weren't able to develop design.
I just want to get an idea.).
Oh man, it either wasn't me or I don't remember. ;)
Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAknBqN4ACgkQ2YZpQepbvXFOegCcDB4gi1f/rOkepVUrF4qgMCZB RvcAoLbFUhSEraOnhWXZJTq1s29E6Bam =9Btc -----END PGP SIGNATURE-----
- Barry Warsaw <barry@list.org>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 23, 2009, at 10:20 AM, Patrick Ben Koetter wrote:
I am collecting information for my work on the MM3 Webinterface while we meet at PyCon 2009 sprint.
Which I'm really looking forward to! Apologies for not responding
sooner.
I guess you have work to do, too. ;)
So far I have found the "Summer of Code summary" <http://wiki.list.org/display/DEV/2006/08/20/Summer+of+Code+summary>.
Any other information/writing I should collect and read before we
meet?The only other thing to look at is this branch:
https://code.edge.launchpad.net/~mk2s/mailman/restserver
It's the work that Maki and Andrew did at last year's sprint. This is
for the Mailman 2.2 branch, but there's some interesting work there
regarding the REST server. I don't know if we should use this branch in the 3.0 version, but it's worth discussing as a starting point.
Agreed. Same idea here.
I also believe I had seen a page where you (?) had noted a link for a design you favoured, but I can't find it. Can you post the link or come up with a list of sites you like? (Not that we weren't able to develop design. I just want to get an idea.).
Oh man, it either wasn't me or I don't remember. ;)
Aesthetic design is something we can turn to later. I for myself want to use our sprint time to work on information architecture, client features etc.
I am currently working on a proposal to rearrange the information structure and I am writing down some basic requirements we should want from the interface (W3A, etc.).
I'll put it up on a wiki and send the link to the list as soon as I am done.
This should put us in the middle of work and not at its beginning when we meet.
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 45227227 81669 München Telefax +49 89 45227226
Amtsgericht München Partnerschaftsregister PR 563
- Patrick Ben Koetter <p@state-of-mind.de>:
Aesthetic design is something we can turn to later. I for myself want to use our sprint time to work on information architecture, client features etc.
I am currently working on a proposal to rearrange the information structure and I am writing down some basic requirements we should want from the interface (W3A, etc.).
Here's the link to a wiki I've put up to get started:
<http://mailman.state-of-mind.de/wiki/doku.php>I will add more as I get to it. Comments, ideas, improvements are welcome. The server part, for example, is completely empty at the moment...
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 45227227 81669 München Telefax +49 89 45227226
Amtsgericht München Partnerschaftsregister PR 563
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mar 20, 2009, at 6:22 PM, Patrick Ben Koetter wrote:
Here's the link to a wiki I've put up to get started:
Hi Patrick,
Do you think the Mailman wiki would be a better place for this?
I will add more as I get to it. Comments, ideas, improvements are
welcome. The server part, for example, is completely empty at the moment...
One thing we discussed at last year's sprint, is the model that the
REST interface will have full admin access to Mailman's data model.
I.e. it will by design be fully authenticated. The reason for this is
that we'd like it to act as an API that other systems can use to
integrate mailing list services into their systems. For example, if
you had a web site running PHP that you wanted to use Mailman for your
mailing lists, it could use this REST API to control and query Mailman.
What this means though is that when you deploy Mailman's REST
interface, you must take care to protect it. You wouldn't want to
expose it to the internet for example. You'd want to make sure that
its interface is accessibly on via your data center, or via localhost
if you were running a turnkey standalone system.
Still, this provides great advantages, such as the ability for us to
ship a web interface as an add on, and for sites to easily swap out
the web interface, or create their own ways of accessing and
controlling Mailman without having to write Python code (which they
can do in MM2 and will be able to do in MM3, though few sites
apparently do this).
So while an account/login model is necessary (e.g. for the email
interface), it needn't be required for accessing the REST API.
Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAknHnJYACgkQ2YZpQepbvXG61QCaAyejP3BWk8XuTVoPWUfgxwy1 0f8An1uI13rnc97QoLJg/gQTBvmU/WW7 =lnPY -----END PGP SIGNATURE-----
- Barry Warsaw <barry@list.org>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mar 20, 2009, at 6:22 PM, Patrick Ben Koetter wrote:
Here's the link to a wiki I've put up to get started:
Hi Patrick,
Do you think the Mailman wiki would be a better place for this?
Yes. It keeps everything in one place. I would have to work around the freemind mindmap flash fancy stuff though, which I've just fallen in love with. But let's not let this get in the way.
How do we do it? Do I get write access to Mailman wiki?
I will add more as I get to it. Comments, ideas, improvements are
welcome. The server part, for example, is completely empty at the moment...One thing we discussed at last year's sprint, is the model that the REST interface will have full admin access to Mailman's data model. I.e. it will by design be fully authenticated. The reason for this is that we'd like it to act as an API that other systems can use to integrate mailing list services into their systems. For example, if you had a web site running PHP that you wanted to use Mailman for your mailing lists, it could use this REST API to control and query Mailman.
We've thought about different client technologies too. That's the client technology part I wrote about in the wiki.
Which we didn't discuss was fully authenticated access for the REST server by design. If I understand this correctly than any party that is able to communicate with the REST server will have full admin access to Mailman's data model. In other words: It's upon any REST client to protect the REST server from abuse.
I feel a little uneasy not having the server control that itself unless we find a good way to control who may connect to the server or the server is able to identify valid clients by some client identity (ACL).
What this means though is that when you deploy Mailman's REST interface, you must take care to protect it. You wouldn't want to expose it to the internet for example. You'd want to make sure that its interface is accessibly on via your data center, or via localhost if you were running a turnkey standalone system.
I was thinking of TLS client/server authentication for open networks. Not that I have spent time yet to find out if Python (REST) tools provide such functionality - I am sure it does, but given my low Python experience, I'd rather verify...
Still, this provides great advantages, such as the ability for us to
ship a web interface as an add on, and for sites to easily swap out the web interface, or create their own ways of accessing and controlling Mailman without having to write Python code (which they can do in MM2 and will be able to do in MM3, though few sites apparently do this).
Same idea here.
p@rick
So while an account/login model is necessary (e.g. for the email
interface), it needn't be required for accessing the REST API.Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAknHnJYACgkQ2YZpQepbvXG61QCaAyejP3BWk8XuTVoPWUfgxwy1 0f8An1uI13rnc97QoLJg/gQTBvmU/WW7 =lnPY -----END PGP SIGNATURE-----
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mar 23, 2009, at 10:55 AM, Patrick Ben Koetter wrote:
Yes. It keeps everything in one place. I would have to work around the freemind mindmap flash fancy stuff though, which I've just fallen in
love with. But let's not let this get in the way.How do we do it? Do I get write access to Mailman wiki?
You should have write access just by virtue of having an account on
the wiki. There are only a few pages that aren't generally writable
by every logged in user. If you're having a problem with a specific
page, let me know.
We've thought about different client technologies too. That's the
client technology part I wrote about in the wiki.Which we didn't discuss was fully authenticated access for the REST
server by design. If I understand this correctly than any party that is able to communicate with the REST server will have full admin access to
Mailman's data model. In other words: It's upon any REST client to protect the REST
server from abuse.
That's basically correct.
I feel a little uneasy not having the server control that itself
unless we find a good way to control who may connect to the server or the
server is able to identify valid clients by some client identity (ACL).
It depends on whether we view the REST API as a user feature or an
admin interface. I've always thought about it as the latter, but I'm
open to other opinions. OTOH, I think there's a lot of functionality
that a privileged process could need, that the general public won't
need at all. Another way to think about it is that there doesn't need
to be just one REST API.
What this means though is that when you deploy Mailman's REST
interface, you must take care to protect it. You wouldn't want to expose it
to the internet for example. You'd want to make sure that its interface is accessibly on via your data center, or via localhost if you were
running a turnkey standalone system.I was thinking of TLS client/server authentication for open
networks. Not that I have spent time yet to find out if Python (REST) tools provide such functionality - I am sure it does, but given my low Python
experience, I'd rather verify...
I'm not sure about this either. Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAknIH8AACgkQ2YZpQepbvXHdPACeOlFuUp985yiVMpDqcMUEjIyc 3rcAoJukYnubROsC9yK1SMt6KV7yjFBk =yOAo -----END PGP SIGNATURE-----
- Barry Warsaw <barry@list.org>:
How do we do it? Do I get write access to Mailman wiki?
You should have write access just by virtue of having an account on the wiki. There are only a few pages that aren't generally writable by every logged in user. If you're having a problem with a specific page, let me know.
I'll give it a try later.
We've thought about different client technologies too. That's the client technology part I wrote about in the wiki.
Which we didn't discuss was fully authenticated access for the REST server by design. If I understand this correctly than any party that is able to communicate with the REST server will have full admin access to Mailman's data model. In other words: It's upon any REST client to protect the REST server from abuse.
That's basically correct.
I feel a little uneasy not having the server control that itself unless we find a good way to control who may connect to the server or the server is able to identify valid clients by some client identity (ACL).
It depends on whether we view the REST API as a user feature or an admin interface. I've always thought about it as the latter, but I'm open to
It's probably both, depending on the users role.
other opinions. OTOH, I think there's a lot of functionality that a privileged process could need, that the general public won't need at all.
That's what I think, too.
Another way to think about it is that there doesn't need to be just one REST API.
Yes and I think this would make maintaining code, setting the whole system up and configuring it more complicated.
Currently one REST server that uses a role model to determine access level to MM's data model seems the best approach to me. I am open to suggestions.
What this means though is that when you deploy Mailman's REST interface, you must take care to protect it. You wouldn't want to expose it to the internet for example. You'd want to make sure that its interface is
Exposing it to the internet is a typical use case in my eyes e.g. run the server on the internet, but control it from a different host. I can see mailman providers offering access to their MM server to customers who integrate their client on their servers - on the internet.
accessibly on via your data center, or via localhost if you were running a turnkey standalone system.
I was thinking of TLS client/server authentication for open networks. Not that I have spent time yet to find out if Python (REST) tools provide such functionality - I am sure it does, but given my low Python experience, I'd rather verify...
I'm not sure about this either.
We should check. Client/server communication will send/receive personal data that IMHO should always be protected during transport regardless of the REST data access control model we choose.
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 45227227 81669 München Telefax +49 89 45227226
Amtsgericht München Partnerschaftsregister PR 563
- Patrick Ben Koetter <p@state-of-mind.de>:
- Barry Warsaw <barry@list.org>:
How do we do it? Do I get write access to Mailman wiki?
You should have write access just by virtue of having an account on the wiki. There are only a few pages that aren't generally writable by every logged in user. If you're having a problem with a specific page, let me know.
I'll give it a try later.
Any special place I should migrate our wiki to? These locations already exist, but I wouldn't want to modify their content:
<http://wiki.list.org/display/DEV/REST+Interface> <http://wiki.list.org/display/DEV/Web+Interface>
I could create sub-pages.
Any preferences, ideas?
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mar 24, 2009, at 5:16 AM, Patrick Ben Koetter wrote:
- Patrick Ben Koetter <p@state-of-mind.de>:
- Barry Warsaw <barry@list.org>:
How do we do it? Do I get write access to Mailman wiki?
You should have write access just by virtue of having an account
on the wiki. There are only a few pages that aren't generally writable
by every logged in user. If you're having a problem with a specific page,
let me know.I'll give it a try later.
Any special place I should migrate our wiki to? These locations already exist, but I wouldn't want to modify their
content:<http://wiki.list.org/display/DEV/REST+Interface> <http://wiki.list.org/display/DEV/Web+Interface>
I could create sub-pages.
Any preferences, ideas?
You could either add to the bottom of those pages (which will make
them easier to garden later), or you could make them subpages of
http://wiki.list.org/display/DEV/PyCon+Sprint+2009
BTW, has the wiki been slow for anybody else? Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAknIvE4ACgkQ2YZpQepbvXHa+ACfcSFh4QtSx/TCE/v/MWw321ed GVAAoKEEQ4NB29BVNr1L9AjPM9v9R2VC =3CN4 -----END PGP SIGNATURE-----
- Barry Warsaw <barry@list.org>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mar 24, 2009, at 5:16 AM, Patrick Ben Koetter wrote:
- Patrick Ben Koetter <p@state-of-mind.de>:
- Barry Warsaw <barry@list.org>:
How do we do it? Do I get write access to Mailman wiki?
You should have write access just by virtue of having an account
on the wiki. There are only a few pages that aren't generally writable
by every logged in user. If you're having a problem with a specific page,
let me know.I'll give it a try later.
Any special place I should migrate our wiki to? These locations already exist, but I wouldn't want to modify their
content:<http://wiki.list.org/display/DEV/REST+Interface> <http://wiki.list.org/display/DEV/Web+Interface>
I could create sub-pages.
Any preferences, ideas?
You could either add to the bottom of those pages (which will make them easier to garden later), or you could make them subpages of
I'll make them subpages of Sprint+2009.
BTW, has the wiki been slow for anybody else?
Yep.
p@rick
Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAknIvE4ACgkQ2YZpQepbvXHa+ACfcSFh4QtSx/TCE/v/MWw321ed GVAAoKEEQ4NB29BVNr1L9AjPM9v9R2VC =3CN4 -----END PGP SIGNATURE-----
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
- Barry Warsaw <barry@list.org>:
http://wiki.list.org/display/DEV/PyCon+Sprint+2009
BTW, has the wiki been slow for anybody else?
It's so slow at the moment it's a pain to work with. Any chance to bring this back to normal?
thanks,
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
participants (4)
-
Barry Warsaw -
Mark Sapiro -
Patrick Ben Koetter -
Terri Oda