> So if you have already developed some stuff, I > certainly would love to see you put it on the table > as a candidate for the Mailman 3 default > archive web UI.
Yes. My CSLA code is on the table for MM2 or 3. It's python, and it's BSD. More than that, if you folks want it, I'm happy to retool/rewrite it as needed to make it suitable. (it has lots of great features, but i havn't touched it in a long time and it could be better) I'll put up a demo of the mailman list in CSLA tomorrow so folks can check it out. I also have "some experience" with this space, and by that I mean mountainous-experience. I coded/managed/architected several versions of eGroups/Yahoo Groups and Google Groups, including the listprocessor, schema design, and a few different python mail-to-html formatters. I also wrote my own personal gmail-like web-mailer in python, which someday I'll get around to open-sourcing. Can you share something about dependency philosophy (besides licensing) in Mailman? Currently CSLA uses Clearsilver templating (BSD c-module) and sqlite (public domain) storage.. both of which can be included directly as source to make installation easy, but they are both c-modules. I'm quite fond of the Clearsilver orm-to-templates toolchain, which is in use for lots of big sites. However, I also recognize it's not that popular in the python commmunity, mostly because we don't promote it, but also because the template processor c-module (for performance) instead of pure python. If it's necessary I could convert CSLA to use django templates, though they have a nasty design/performance problem with the orm that I think would prevent me from using it (unless I fixed it). I'm not a fan of javascript client-side rendering because of the generally poor performance, poor mobile compatibility, and lack of benefit for this kind of application. > Doing a *better* job of formatting HTML (than pipermail) is easy. > Doing a *good* job is going to be relatively hard, though. Isn't that the truth. Back at Egroups there was a time where it seems like we used to tweak the formatter almost daily. Deciding when preformatting is necessary vs harmful is a real pain. My CSLA python code has a fairly stable msg-to-html formatter that I've been happy with for a long time. It does very aggressive automatic repetitive text eliding for thread-display, so you can read many messages in a thread in a single page without massive quote pileup. View-source is provided for the unfortunate case where it does something bad. > AIUI, the current philosophy is that > > (1) the communication from Mailman to the archivers > will be via LMTP/SMTP, including a Mailman-specific > header to identify the message's permalink (currently > the SHA1 hash of the message ID in BASE32 > format, IIRC); and Using SMTP for an included archiver would require it be a long running server instead of merely a handler. Are we talking about third-party-site archivers here? > (2) the summary, search, and retrieval UI will be a > separate application from Mailman per se, which will > communicate with Mailman via the REST API for > authentication and user configuration purposes. That makes sense... CSLA doesn't currently have any concept server-auth. The only stateful features it has are view-preferences and read-state, neither of which are important enough to require a password. It uses a password-less system which uses cookies for prefs and a 'read state userid' which a user can manually set if they want. I like it, because it doesn't require login to get some basic browsing prefs and features. Hooking up an auth system would be necessary for some of the editing ideas in the document I read, or to allow online posting. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://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: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
