Re: [Mailman-Developers] GSoC 15 - Interested in contributing to Hyperkitty
In my proposal I suggested using any of several asynchronous job queue libraries, such as Celery or Huey. These all use redis as a back-end. Because I have no experience with asynchronous job queues, I'm not sure if this is too much baggage for our purposes. Maybe we just don't want the extra dependencies. Yeah, we don't want to add another database or an AMQP server just for that. We must keep it simple for admins to deploy. Regarding cron jobs, there's also django-background-task which is a simple django addon that might do what we need. Again, if we don't want/need the extra dependency, rolling our own cron job should be fairly straight-forward. I'm already using the jobs infrastructure provided by the django-extensions package: http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html I did consider django-background-task but django-extensions seemed like a better fit, because django-background-task seems written for delayed tasks, not periodic tasks (well, a task could call itself again when done, but it seems like a hack). I'm not opposed to switching to django-background-task if we use the delayed job feature or if we need the extra flexibility of choosing exactly how many seconds apart we want our tasks to run. If we choose to pre-build the mbox files, we can't simply have them served through the webserver, because some lists are private Then there is also an authentication step? Yeah, we must use HyperKitty's authentication and check if the user is allowed to see the archive. So the files can't be served by the webserver like static files. I noticed on the test server that I can't actually look at any of the mailing lists because they're all private. If you're looking at lists.stg.fedoraproject.org, it's currently very outdated (still running the Python2-compatible branch of Mailman 3). I have another test server with more current info if you want, but I break it regularly. It's lists-dev.cloud.fedoraproject.org When we create the mbox file, do we simply note that an attachment existed (e.g. Attachment: myattachment.txt) or do we actually put the attachment in the mbox? AFAIK mbox is a plaintext format, so if the latter is the case then I'm not exactly sure how this would work... We do put the attachment in the mbox, as a MIME component like in every email. If you choose view source when looking at an email with attachments, you'll see how it's done. Are there going to be any issues handling unicode foreign characters or with file locks? Right now it looks like we should only have one process handling the mbox, but is it possible that more than one could be spawned somehow? No, mbox files are not designed for concurrent writes, so it's better to have a single process write to them. Another possible nice-to-have feature I thought of yesterday is a download link that scripts can use to get archives (e.g. /download?year=xmonth=y). On the other hand, maybe this is just a security risk that has no actual use case, but I'd still like to have a second opinion on this. Well, there still is the authentication issue. Aurélien ___ 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 - Proposal A Dashboard for Admins/Owners/Moderators
Hi guys, I have updated my proposal for A Dashboard for Admins/Owners/Moderators project. I have tried to address the issues raised. Reviews on it are welcome. Regards, Shreyas Lakhe ___ 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] Accessibility of interfaces
Dave You seem to have an interest in Mailman being accessible. Care to share some requirements/requests/tips/pointers for the various people who are writing user interface code that talks to Mailman. I’d like to take this sort of thing into account early in the process if possible so now is a good time to talk about what you want/need. as ___ 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] Javascript Client for Mailman
At 01:51 AM 3/25/2015, Ana Badescu wrote: Hello, While writing my proposal I came across 2 important issues related to the Javascript Client for the Mailman project that have yet to be raised: 2. I'd also like to make part of the project, a node.js application that uses the Mailman Javascript client and offers all the functionality Postorious does. Is that a good idea? This doesn't make the scope of the project too large or unattainable. Please remember that anything you develop should be accessible to disabled persons. This is possible with JAVA generally, but means some planning, using the right libraries etc. Dave David Andrews and long white cane Harry. E-Mail: dandr...@visi.com or david.andr...@nfbnet.org ___ 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] Javascript Client for Mailman
Hello, Well, thanks Stephen for adding and clarifying things. Actually, I have also submitted a proposal on the same and have been doing a lot of research work on this for the past few weeks. So, I added up on the callback stuff. Actually, I felt that it would be lots of work if someone want to have a entire postorius like thing for node as part of the GSoC project. So, for the time focusing on the port will be the best thing. So, I agree with Florian here. As far as the reasons you have suggested for not commenting, I will go with (c) option and the reason being I was lacking on the term Student but now things are more clear :-) On Thu, Mar 26, 2015 at 7:21 AM, Stephen J. Turnbull step...@xemacs.org wrote: Ankush Sharma writes: I cannot comment on this as I am a student just like you. First, thank you very much for commenting in the first place! Students helping each other is one of the most exciting aspects of GSoC. But I think you misunderstand student in the context of GSoC. It's an accounting term. Students get paid, mentors get tired, er, T-shirts, that's it! Mentors get T-shirts! Other than that, we're all Mailman developers. You can and should comment on anything where you have an opinion. Some developers have more experience and skills, some have a natural talent for programming or design or building UIs and others don't have any of the above but need a feature or bugfix, and nobody else seems to want to do it. The good reasons for not giving your opinion are (a) you don't have one (a common reason for those with less experience in the project), (b) somebody's already expressed pretty much the same opinion (in cases where values differ, you might even add a +1 here), and (c) you're waiting for somebody else to comment first for some reason. That's a little bit oversimplified, but it's important. I don't know if it's made explicit in the GSoC handbooks, but if you get a chance to talk to Carol or Cat you'll hear that one of the things they enjoy most is hearing about students who become mentors. That's a core value in GSoC: the kind of professional growth that turns students into teachers. And it happens in just one or two years for many students. New members normally don't get that experience in a company (unless you're running it :-). They also hear stories about how that assumption of responsibility carries over to the new mentor's school and employment opportunities. ___ 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] GSoC 15 - Interested in contributing to Hyperkitty
I'm already using the jobs infrastructure provided by the django-extensions package: http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html Cool. I didn't know about this extension, but it looks like it does what we need. So the background process would be its own file in the jobs directory, and we could leave it to the admin to setup the crontab? I have another test server with more current info if you want, but I break it regularly. It's lists-dev.cloud.fedoraproject.org Thanks for linking this. I got my own local dev server working yesterday, but this one is much more populated. We do put the attachment in the mbox, as a MIME component like in every email. I see how this works now. Are the attachments always Base64 encoded? Another possible nice-to-have feature I thought of yesterday is a download link that scripts can use to get archives (e.g. /download?year=xmonth=y). On the other hand, maybe this is just a security risk that has no actual use case, but I'd still like to have a second opinion on this. Well, there still is the authentication issue. I guess getting the scripts to authenticate would be a little complicated, but otherwise does this seem like something worth including? If my proposal gets accepted, I'm ok with leaving this as an open question until it becomes clear whether or not I'm going to have extra time at the end of the summer. Thanks, David On Thu, Mar 26, 2015 at 7:33 AM, Aurelien Bompard aurel...@bompard.org wrote: In my proposal I suggested using any of several asynchronous job queue libraries, such as Celery or Huey. These all use redis as a back-end. Because I have no experience with asynchronous job queues, I'm not sure if this is too much baggage for our purposes. Maybe we just don't want the extra dependencies. Yeah, we don't want to add another database or an AMQP server just for that. We must keep it simple for admins to deploy. Regarding cron jobs, there's also django-background-task which is a simple django addon that might do what we need. Again, if we don't want/need the extra dependency, rolling our own cron job should be fairly straight-forward. I'm already using the jobs infrastructure provided by the django-extensions package: http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html I did consider django-background-task but django-extensions seemed like a better fit, because django-background-task seems written for delayed tasks, not periodic tasks (well, a task could call itself again when done, but it seems like a hack). I'm not opposed to switching to django-background-task if we use the delayed job feature or if we need the extra flexibility of choosing exactly how many seconds apart we want our tasks to run. If we choose to pre-build the mbox files, we can't simply have them served through the webserver, because some lists are private Then there is also an authentication step? Yeah, we must use HyperKitty's authentication and check if the user is allowed to see the archive. So the files can't be served by the webserver like static files. I noticed on the test server that I can't actually look at any of the mailing lists because they're all private. If you're looking at lists.stg.fedoraproject.org, it's currently very outdated (still running the Python2-compatible branch of Mailman 3). I have another test server with more current info if you want, but I break it regularly. It's lists-dev.cloud.fedoraproject.org When we create the mbox file, do we simply note that an attachment existed (e.g. Attachment: myattachment.txt) or do we actually put the attachment in the mbox? AFAIK mbox is a plaintext format, so if the latter is the case then I'm not exactly sure how this would work... We do put the attachment in the mbox, as a MIME component like in every email. If you choose view source when looking at an email with attachments, you'll see how it's done. Are there going to be any issues handling unicode foreign characters or with file locks? Right now it looks like we should only have one process handling the mbox, but is it possible that more than one could be spawned somehow? No, mbox files are not designed for concurrent writes, so it's better to have a single process write to them. Another possible nice-to-have feature I thought of yesterday is a download link that scripts can use to get archives (e.g. /download?year=xmonth=y). On the other hand, maybe this is just a security risk that has no actual use case, but I'd still like to have a second opinion on this. Well, there still is the authentication issue. Aurélien ___ 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:
[Mailman-Developers] Regarding GSoC 2015
Hello Sir, My name is Aneesh Anil, and I'm very much interested in contributing to Mailman 3 project. But because I don't have any prior experience in any real world projects I am confused as to what to select. But since I have knowledge of javascript/html with python I think I would do better if I started working on : 1) A Dashboard for Admins/Owners/Moderators ,or 2) Subscriber profile page (Also taking in the fact that these are beginner friendly) I also am working on increasing my knowledge of Django. If you would be kind enough to suggest a project which would be better for me to understand and actually grasp the real world coding concepts It will be much appreciated. Thanking You , Aneesh Anil ___ 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
