On Mar 27, 2012, at 10:34 AM, Stephen J. Turnbull wrote: >Pipermail is going the way of the dodo, yes, but there will be something >bundled with Mailman, I'm pretty sure.
fsvo "bundled" :) >(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 Kind of. Communication *into* Mailman is via LMTP, but sending a message out of mm3 into the archiver can be hidden behind the IArchiver interface. The prototype archiver, just opens a maildir and adds the new message to that. The mailarchive implementation drops the message into the outgoing queue, but with a recipient as specified in the configuration file. The mhonarc archiver calls a subprocess and pipes the message's bytes to that process's stdin. The moral is that whatever you need to do to get the message into the archiver, you can do it. You're right about the algorithm for calculating the X-Message-Id-Hash. Full details are on the wiki. The intent here is to be able to calculate the URL to the message in the archiver without actually having to communicate with the archiver. >(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. Yep. I've also been thinking; we have an IMessageStore interface which currently isn't much hooked up in any way. It's possible that a specific archiver could satisfy the IMessageStore API as well, and that eventually we could implement things like a mail command that, given a Message-ID (or its hash) would send you back the message from the store. >Some ideas that have *not* been elaborated as "philosophy", but >which I think are consistent with various desiderata and Barry's >general approach and specific statements are > >(3) an archiver Handler for the pipeline will be provided, which >will store posts in maildir format and do nothing else; and I've been thinking that the prototype archiver could be this thing. Well, it already essentially *is* that thing! So, it's not in a handler, but gets invoked from the ArchiveRunner. >(4) a simple default summary/search/retrieval application will >be bundled with (but have a separate development cycle from) >Mailman. +1 >Even if that's not the current philosophy <wink/> that's the >direction I would propose. > >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. Definitely. My intent with mm3 is to provide an enabling platform for archiver developers. I think there's lots of opportunity for experimentation here, so let's make sure we get the API between mm3 and a generic archiver right. We'll see what pans out and then we can choose a preferred default that we can bless and bundle in some kind of sumo release. Cheers, -Barry _______________________________________________ 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
