On Tue, Mar 27, 2012 at 9:11 AM, Toshio Kuratomi <a.bad...@gmail.com> wrote: > On Mon, Mar 26, 2012 at 03:20:05PM -0700, David Jeske wrote:
> 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. I don't understand why this is an issue. Third party archives (no "r"!) are going to want to have their own copies of the posts, and will be heavily duplicated in any case (if only because they store stuff on RAID and backup regularly :-). Communicating with them via SMTP will be fine, and LMTP provides a reasonable way to handle local archives efficiently -- you can even just use a virtual user and a standard MDA for the purpose. If a third party wants to provide archiving service, but allow the list to supply authentication and user configuration information, that's another kettle of fish, but that's not a question of the archiver itself, that's going to be part of the Mailman 3 REST API per se. > 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. Agreed, but the storage issue is easy to solve for the Mailman site itself. Just provide a simple Handler to stuff posts into a maildir format mail folder (as noted above, this can communicate with a standard MDA via LMTP, and "require" that all third party archive UI software support that format. Maybe if space is that big an issue, provide a maildir-in-zipfile backend. If they want to do something else (eg, access an IMAP store or stuff it into a PostgreSQL database) they can provide their own handler for that ... surely this is trivial? > (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.) Yes, let's stay away from copyleft, period, to get a standard archiver that commercial sites and developers will be comfortable with extending. I know people are disgusted with Plesk and especially cPanel, but (a) GPL hasn't stopped those folks keeping their sources away from general public, and even with AGPL, *we* would have to keep track of *their* releases to get our hands on their changes in any timely fashion -- which half the time we don't want anyway! -- and (b) what we're doing is all about UI in some sense. Even the pipeline architecture of core Mailman is about allowing users (the script-able but not always program-able list and site admins) to easily make changes to their lists' configurations. UI design is necessarily visible, and it's unlikely to be that much of a challenge to reproduce their changes. The hard part will be getting the internal design past Barry, anyway (which is one reason why some of the more frequently-requested features provided by cPanel Mailman, like duplicate list names across virtual servers, haven't been added in the past). _______________________________________________ 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
