On 2/28/20 5:52 AM, Stephen J. Turnbull wrote:
Too bad. I really sympathize with your goals but am unlikely to be able to contribute directly to implementation (assuming an eventual open-sourcing). Never learned PHP, not going to do it anytime soon. That's OK, the point of REST is so*you* *can* do that. I can only speak for myself, but we can help to some extent on the Python side of the REST interface.
Help with interfacing with Mailman Core via REST will be nice to have. My programmer was happy to hear that Mailman core utilized REST but I am sure he may have some questions. I have a Discord server setup for development communication purposes that I can add you and hopefully Mark Sapiro to it if you want. We are also setting up the project on Gitlab as a private repository for now.
Usability testing is also very important and the new admin interface will need it. This is another part someone like you can be of an immense help. I am open to any sort of volunteers at this point.
A word of advice: we, too, talked about "modern forum software and interfaces that users expect", but implementing them well is a lot harder than we expected. I'm not saying it's too hard for your developer, but stay on top of that project! Mail is hard to combine with forums, and it's easy to stray into the weeds.
I agree and understand. The forum side is not being considered at this time until we get the admin interface nailed down. Right now I am looking at Discourse as a motivation for developing the forum side. I also think for mailing lists to survive in the future, integrating both approaches to communications is what modern users are looking for. I also think the approach Mailman 3 core did with using a database and REST api is brilliant and forward thinking. I just think the current interfaces and the decision to go with Django has hurt Mailman 3 rather than help it.
I also mirror Jim's question of who is the "we" in this conversation. Why wasn't I invited? :-D
Sure, but that's still quite a ways away. The main issues I can see would be related to TLS, where old versions of the protocol seem to be deprecated more and more rapidly, but it's probably easier to patch Python 2 for that than to port Mailman 2 to Python 3. Sure, there may be non-TLS CVEs against Python 2, but I really can't see them being as serious as the kinds of issues that Mailman 2 itself, not to mention any site with mail service, would have.
What prevents Mailman 3 from replacing Mailman 2 completely? Is it because of the interfaces for Mailman 3 totally left Mailman 2 behind or was it the decision to use Django? Cannot Mailman 3 be used as a standalone 'traditional' mailing list without the need for something like Hyperkitty? Can Pipermail be modified to work with Mailman 3 as perhaps a stopgap for Mailman 2 users to feel more comfortable with migrating to Mailman 3? I host hundreds of Mailman 2 lists and I cannot get my clients interested in Mailman 3. It doesn't have all of the features that Mailman 2 has when it comes to list settings, at least not visible and Hyperkitty is just not impressive to look at when it comes to providing a community feel.
I want to research to see if it is possible to provide a browser base interface to convert/import a Mailman 2 list into a Mailman 3 list without the need of using a command line. Again I am just focusing on the list (admin) settings to be imported at this point not archives into a forum setting.
This makes no sense to me. If your problem with Django is that it's written in Python, you've got the REST interface. That's as far as our responsibility goes. See "REST is the approach" below.
I assume Django was primarily chosen was because it was written in Python. Maybe I am wrong here. My main problem with Django is you have to handle a 3rd interface with Mailman 3. So we have three: Postorius, Hyperkitty, and Django. When it comes to a U.I. perspective, Django's admin interface leaves a lot to desire. I am hoping to merge the need to use two interfaces for administration of a mailman 3 list to one, beautiful, easy to use, superfast and glorious administrative interface. In other words, One Admin Interface To Rule Them All. I am having some fun here but there is a lot of truth that describes my intentions. When I first explored using Mailman 3 and I came across the word: Django, I said "what the heck is that???". I am pretty sure I am not the only with that response. I am still, btw, saying that about Django because I am having a very difficult time wrapping my head around its logic.
That's not a problem we created. Our recommendation is, as it always has been, build from source. And the problem is not going to go away. Users want turnkey packages such as containers, distros can't be stopped from building distro packages. If you open source your interfaces, you'll run into the same issues.
I am not trying to blame anyone here. I just seems to me there is a lot of confusion with the use of Mailman 3.
The problem is the discrepancies between the versions. Once bounce processing shows up in Postorius that discrepancy will spread even further. The confusing state of installation documentation is also a serious problem. I ended up writing my own that I can get consistent results from with installing Mailman 3 on new servers. So one of my goals in coming up with a new approach is to make the full setup of a Mailman 3 server far easier to do AND document.
REST*is* the "Mailman 3 approach" to interfacing. Historically, at the time Mailman 3 core got whipped into shape to start beta testing, we went with Django for Postorius, because it was the "hot" framework of the day, and that's what the developers who volunteered wanted to work with. Of course it had to be a Python framework since we'd be maintaining it. HyperKitty was a little bit different: the Fedora (or Red Hat?) people wanted Mailman 3 for internal reasons, and they contributed a pile of labor, and (AFAIK) independently chose Django and developed the UI based on it (which is why we have two separate Django configs).
That is fine but what I did not see is the use of U.I. designers. Developers make the WORST U.I. designers. U.I. design in my opinion will seriously hinder the acceptance of an application no matter how great it is. This is good information to know regardless so thank you for sharing.
*However*, the original idea was that*we* didn't know much about UI development, especially the peripheral features of archiving such as search and access control, and we wanted to encourage third parties to develop their own, or to integrate Mailman lists into their larger platforms which already provided user interfaces.
So where was this encouragement? What larger platform did you have in mind to integrate Mailman lists into? I am still surprised to see no one has come up with a new interface for Mailman 3. I think it is important to find out why that is but maybe in another discussion thread.
From what I can see Mailman 3 core is rock solid. Using a database and the REST api was a great move so for me, that leaves the actually public facing interfaces to be scrutinized and that is what I have done. Based upon my observations I decided to try to do something about what I see as some glaring weaknesses in Postorius/Django Admin/Hyperkitty.
The main Postorius devs aren't hanging out here, and we get only a little contact in the summer with the HyperKitty devs since the Fedora support got cut three or four years ago.;-) If I know Mark he started a little miffed but calmed down quickly since diverse UIs have always been part of the vision.
Mark is awesome and I have a great working relationship with him via these lists throughout the years. I believe I will have that with him in the future as well.
As far as I know this is precisely what we wanted to happen in the first place. We knew that we would have to have a bundlable user/admin interface and an archiver with a web interface, but the original intent was not that they dominate Mailman installations. We should have known better, given the huge popularity of Mailman 2 with Pipermail (oh, Lordy) as the archiver, but hope springs eternal .... I think further discussion should move to mailman-developers, though, and please introduce your UI developer(s) to us on mailman-developers soonish. Nobody has huge amounts of time to put into work on Mailman right now AFAIK, but I expect we will be willing to cooperate on any Mailman features or fixes your developer needs in the REST interface "in good time".
Will do and thank you for your thoughtful reply.
I'm going to be very busy until March 11, but after that I'll have some time. Ginning up a list of REST endpoints is the kind of thing I'm good at, so maybe I personally could start there.
Sounds great! -- Please let me know if you need further assistance. Thank you for your business. We appreciate our clients. Brian Carpenter EMWD.com -- EMWD's Knowledgebase: https://clientarea.emwd.com/index.php/knowledgebase EMWD's Community Forums http://discourse.emwd.com/ ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
