Re: [Mailman-Developers] any interest in a new built-in web-archive? (i.e. pipermail replacement)
On Mar 26, 2012, at 06:07 PM, David Jeske wrote:
I highly recommend reconsidering this and including a standard archiver with mailman. If the number of sites that use pipermail is any indication, I think failing to include something will basically mean lots of lists without any archives.
I think you're right. People want a turnkey solution - download one thing, run one command, and you've got everything you need. Of course, with mm2, you *don't* though because Pipermail never provided searching for example.
There are lots of questions to ask about how we in the Mailman project would provide that kind of turnkey solution that includes our best-of-breed services. OTOH, it's also powerful to provide choice and not require any specific bits.
My gut tells me that we're on the right track with Postorius, but that we're pretty far away from being able to bless an archiver right now. It's definitely not something I want to hold up the 3.0 final release for, so we have to find the right way to manage our users expectations.
Understand though that we're constrained in other ways when we start thinking about bundling or officially blessing certain components. Mailman is a GNU project and the core's copyright has been owned by the FSF for over a decade. We require copyright assignments to the FSF. Postorius falls under the same administrative structure, so there's no problem calling it the official GNU Mailman web ui. A bless, bundled archiver will have to probably adhere to the same constraints, or at least we'd have to have that conversation with the FSF about it.
But that absolutely shouldn't stop any other third party archiver from being Mailman 3 compatible.
As I said, like the Python standard library, it's both a blessing and a curse. :)
As for the features it doesn't have from your list: Editing would be easy to add because it's sqlite (deciding on the auth system is probably more of an issue than the editing). Anti-Crawl code is really an issue of configuration for cheap in-memory state-management. NNTP is well. that would be a big job that I doubt will be bitten off by something as "small" as a list archiver.
Why can't we kill off Gmane while we're killing off Gmail, and *Groups? :).
What is the REST UI used by? CSLA supports RSS. When it comes to a more involved REST UI, what software would be hitting it? I don't think I'll understand your other API/REST points until I see an answer to this.
I'm a list owner and someone requests that a post containing private information be taken down.
As a drive-by archive user, I want to request that a message get sent to me so that I can reply to it in my mail reader as if I had received the original.
I run a question/answer forum that gateways a list, and I want to +1 really helpful messages, or give some extra kudos to really helpful users.
-Barry
On Mar 27, 2012 8:47 PM, "Barry Warsaw" <barry@list.org> wrote:
.... but that we're pretty far away from being able to bless an archiver right now.
I just want to be clear, that I'm obviously not asking for anyone to bless a specific archiver and roll it into the distribution.
I'm trying to get some idea what requirements an archiver would need to meet for you folks to jump for joy and roll it into the MM2 and MM3 distros -- because my goal is to (with respect and fondness) exterminate pipermail for the betterment of all. Along these lines, I've been thinking that in addition to a dynamic rendering system (like CSLA), it might be worth it to include a static-html generation model a bit more like pipermail ... as some sites may prefer it and it's easy to do.
If there is a compatible set of goals I'll gladly offer / retool rewrite my stuff to make folks happy.
.. if requirement #1 is GPL, then sadly I'll have to rethink my extermination plan, because GPL is not a jeske-compatible-license. :)
Why can't we kill off Gmane while we're killing off Gmail, and *Groups? :).
Is that the primary niche for gmane? Folks who want to read mailing lists via NNTP clients? What is the motivation for NNTP support? I don't think it would be too bad to support NNTP clients, it's NNTP sync that is more involved. I just don't know why anyone would want to use an NNTP client anymore.
As for killing off things, don't get me started. I'm very unhappy with the new over-ajax Groups UI, and the fact that they seem to have broke the faceted directory browser. The old html-with-javascript-tweaks is so much faster and lighter on all browsers (especially mobile).
What is the REST UI used by? CSLA supports RSS. When it comes to a more involved REST UI, what software would be hitting it? I don't think I'll understand your other API/REST points until I see an answer to this.
I'm a list owner and someone requests that a post containing private information be taken down.
I would expect the user/list-owner go to the new-builtin-super-cool-mm-archive-web-ui to request/approve-takedown.. which would have CGIs and UI to directly modify it's data. The only REST API I see is for validating the user-cookie, checking his auth-permissinos, etc.
Is that what you are thinking, or am I missing some part of your thinking?
participants (2)
-
Barry Warsaw
-
David Jeske