On Mar 26, 2012, at 05:11 PM, Toshio Kuratomi wrote: >We'd love to have work done on the archier! I know that we're ditching >pipermail entirely and that archivers are becoming separate from the core >mailman. What I don't know is whether mailman3 will eventually have >a standard archiver which lives outside of the core mailman but is >recommended for installation along with it.
Yeah, who knows? :) >At PyCon a few weeks ago, I demoed hyperkitty which showed some of the >things that a next generation archiver could do. hyperkitty is continuing >to be developed. As I was talking about hyperkitty we touched briefly on >what I think is one of the central conundrums about having only unofficial >third party archivers: how to have a consistent programatic interface >available over http. Grackle is another archiver for mailman that doesn't >have the UI bells and whistles of hyperkitty but it does make an effort to >expose a REST UI to the world. I think that's a beautiful thing. But >I don't like that a site that wanted both would need to run two archivers >that were saving mail into two sets of storage. Really excellent points Toshio. >I think there's several ways we could go about this. > >* We could create a standard REST API that archivers were free but > encouraged to implement. >* We could expand the python API that archivers needed to expose and then > implement the REST API inside of mailman Core (or a re-envisioned, > lightweight Grackle). >* We could promote a standard archiver much as we're going to promote > posterius as the standard admin front-end and that archiver would provide > a standard REST API that others could then emulate. And very good suggestions too. I'm not sure what the best thing to do right now, but I've long thought that the core needs a basic "message store" (as you'll see in the IMessageStore interface, which probably sucks ;). It's possible that the prototype archiver morphs into this thing and that as we expose the IMessageStore to the core's REST API, we'll start to define what we need from an archiver. I agree that having such an API in front of the archiver is a truly beautiful thing. >(One thing I notice about grackle now is that it's AGPL... that's going to >be unpleasant for some sites to run. Perhaps we can change that or get some >changes added to the AGPL.) It may be difficult to change. Canonical's default license on FLOSS it releases is AGPL. If we can make a good case for wanting something different, it may be possible to change. On a separate track, at Pycon you made a persuasive argument about the AGPL's flaws, and since that's an official FSF license, it would be good if "someone" would explore addressing those problems with them. That probably won't be me <wink>. -Barry
signature.asc
Description: PGP signature
_______________________________________________ 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
