Re: [Mailman-Developers] Small change to REST API for held subscription requests
How would user passwords work if not stored in the core? When someone logs in currently I just ask the core if the password is valid and off we go. as On 23 Mar 2015, at 8:19 am, Barry Warsaw ba...@list.org wrote: On Mar 22, 2015, at 09:55 PM, Florian Fuchs wrote: As for the `password` key: It's recognized by mailman.client and exposed within the mlist instance's `requests` property. But it's used nowhere in postorius and I would be surprised if it's used anywhere in hyperkitty (Aurélien...?). I guess it can go away. TBH, I desperately want to purge user passwords from core too! I think they're almost completely unused; the only reason to keep them would be to help Postorious or other REST clients. As for the email/address keys: We can also just keep the `address` key in mailman.client and let it use the same value as `email`. That way we would still have a fallback but the REST API would stay clean and wouldn't send any redundant information over the wire. Cool. Can you notify me when your API changes are pushed to LP, so I can update mailman.client accordingly? Just to keep the window as small as possible where we have non-compatible states in the mailman/mailman.client trunks. Especially during GSoC application week... Will do. I'm working on the subscription policy branch again, and this is a useful refactoring I'm committing before other work. I'm trying to decide whether to commit this to trunk now or when subpolicy lands. Stay tuned! Cheers, -Barry ___ 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%40supercoders.com.au Security Policy: http://wiki.list.org/x/QIA9 ___ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Small change to REST API for held subscription requests
On Mar 23, 2015, at 09:34 AM, Andrew Stuart wrote: How would user passwords work if not stored in the core? When someone logs in currently I just ask the core if the password is valid and off we go. WFM. As I said, the core doesn't (currently) use it, but certainly it's available through the REST API, so if REST clients need it, we'll keep it. -Barry pgpSN1TAEVrAU.pgp Description: OpenPGP digital signature ___ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Common use case archiving via configuration
Andrew Stuart writes: Specifically if would be good if a Mailman admin could define in the Mailman config file a set of destination email addresses and POST urls that archive messages are sent to. This would meet many common archiving needs via configuration instead of code. I think this is a good idea but it scares me. Every archiver is a little bit different, and it's not obvious to me that generic mailto: and http: POST urls are sufficient to cover the kinds of things that archivers might want to do. It could be a noticable maintenance burden. That said, besides mailto and POST, there's NNTP (Gmane, at least), although NNTP also seems likely to need an incoming gateway as well. I’d also include a filesystem/zip archiver which writes each message to a zipped file on the disk. ___ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Small change to REST API for held subscription requests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 22.03.2015 um 02:32 schrieb Barry Warsaw:
I want to make some minor backward incompatible changes to the
JSON representation for pending mailing lists requests, e.g.
subscription holds. You'll see these for example in urls like:
dump_json('http://localhost:9001/3.0/lists/a...@example.com/requests
')
entry 0:
delivery_mode: regular display_name: Anne Person email:
a...@example.com http_etag: ... language: en request_id: ...
type: subscription when: 2005-08-01T07:49:23
The first change is that `type: subscription` requests will change
their `address` key to `email` for consistency with other parts of
the API. Second, there will be no `password` key.
Let me know if this is a problem, and I can copy `email` to
`address` so that both would appear, and add a dummy `password`
key.
As for the `password` key: It's recognized by mailman.client and
exposed within the mlist instance's `requests` property. But it's used
nowhere in postorius and I would be surprised if it's used anywhere in
hyperkitty (Aurélien...?). I guess it can go away.
As for the email/address keys: We can also just keep the `address` key
in mailman.client and let it use the same value as `email`. That way
we would still have a fallback but the REST API would stay clean and
wouldn't send any redundant information over the wire.
Can you notify me when your API changes are pushed to LP, so I can
update mailman.client accordingly? Just to keep the window as small as
possible where we have non-compatible states in the
mailman/mailman.client trunks. Especially during GSoC application
week...
Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJVDyxKAAoJEEceGbPdavl7VicIAIvPKbwYfpAHDHBDNHjQALjZ
eTjz1KjaH/q9cyAQ1rmhttH1emiz5BukKOIvUTxeANc8ooscHXmUN+Prs1ahgebe
tSS7lKvc14kx9QW1HRvbQdnQpYcicNyTSZhTjeD/+RDIaUE+MWaRRxGbcOkHXCHT
OrmXeBSOAYGHPrNsExUcIBwRz8IdjFajQ8FIYS/GddsFeotUBJfQxQ7xdkDJMYkB
6iuPtuWwEKXvbxZLMgPtpCpuxYxOeS+cfQarXCdXLmrwruYNDPK0T16TQOa+QC+o
/3oNR5aKOTWmy3Dg+Jf2+CJ2eKmQ/NPqvWotXkl2h5CdwWu+TB8RZBTA3XQ91Z4=
=v1VH
-END PGP SIGNATURE-
___
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/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Small change to REST API for held subscription requests
On Mar 22, 2015, at 09:55 PM, Florian Fuchs wrote: As for the `password` key: It's recognized by mailman.client and exposed within the mlist instance's `requests` property. But it's used nowhere in postorius and I would be surprised if it's used anywhere in hyperkitty (Aurélien...?). I guess it can go away. TBH, I desperately want to purge user passwords from core too! I think they're almost completely unused; the only reason to keep them would be to help Postorious or other REST clients. As for the email/address keys: We can also just keep the `address` key in mailman.client and let it use the same value as `email`. That way we would still have a fallback but the REST API would stay clean and wouldn't send any redundant information over the wire. Cool. Can you notify me when your API changes are pushed to LP, so I can update mailman.client accordingly? Just to keep the window as small as possible where we have non-compatible states in the mailman/mailman.client trunks. Especially during GSoC application week... Will do. I'm working on the subscription policy branch again, and this is a useful refactoring I'm committing before other work. I'm trying to decide whether to commit this to trunk now or when subpolicy lands. Stay tuned! Cheers, -Barry pgp_rPOPw59Zv.pgp Description: OpenPGP digital signature ___ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Small change to REST API for held subscription requests
Fine with me.
as
On 22 Mar 2015, at 12:32 pm, Barry Warsaw ba...@list.org wrote:
I want to make some minor backward incompatible changes to the JSON
representation for pending mailing lists requests, e.g. subscription holds.
You'll see these for example in urls like:
dump_json('http://localhost:9001/3.0/lists/a...@example.com/requests')
entry 0:
delivery_mode: regular
display_name: Anne Person
email: a...@example.com
http_etag: ...
language: en
request_id: ...
type: subscription
when: 2005-08-01T07:49:23
The first change is that `type: subscription` requests will change their
`address` key to `email` for consistency with other parts of the API. Second,
there will be no `password` key.
Let me know if this is a problem, and I can copy `email` to `address` so that
both would appear, and add a dummy `password` key.
Cheers,
-Barry
___
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%40supercoders.com.au
Security Policy: http://wiki.list.org/x/QIA9
___
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/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] GSoC 15 - Interested in contributing to Hyperkitty
Hello, My name is David Udelson. I am a freshman Computer Science undergraduate at Cornell University. I have 3 years of experience with python under my belt, but I've never contributed to an open source project because I've never known where to begin. I'm hoping GSoC will provide me with that starting point, as well as an opportunity to make some meaningful contributions to the open source community. I'm interested in contributing to the Hyperkitty archiver. Specifically, it looks like some requested features for Hyperkitty include rss syndication for entire mailing lists/specific users/specific threads, and the ability to view entire threads as plaintext and download that plaintext. I have the following questions regarding these features: 1) Are these features definitely expected to be in future releases, or are they just nice-to-haves? If there are more important/pressing issues that the Hyperkitty devs think I could implement instead, I would prefer to work on those. 2) Are both of these features implementable within the GSoC timeline, or should I only pursue one of them? Thanks, David ___ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
