Aurelien Bompard writes:
> Barry writes:
> > One of the advantages of accessing the core through the REST API
> > is that it doesn't matter what clients like HyperKitty and
> > Postorious are written in.
> I'm not exclusively using the REST API though. I'm importing a
> couple interfaces, mostly the archiver interface.
This was a design mistake, I think. An IArchiver really needs to be
in core for two reasons: first, it needs to generate a permalink and
attach it to the message as distributed. Second, it needs to
associate that permalink with the message so the "real" archiver
process will do set that link correctly. For a production-quality
archiver, that's *all* it should do. The archiver itself should be a
separate process, receiving the message and permalink data by IPC.
@Barry: maybe rename IArchiver to IPermalinker? ;-)
Remember, Mailman core is going to be distributing Internet mail.
Except in the case where 100.00% of the users are on one host, that's
going to be the bottleneck on message processing. Archiving simply
does not need to be fast. The archiver can implement LMTP even,
although that would be overkill if we didn't already have an LMTP
server. The simplest approach would be to simply put the
Archive-Permalink header in the message and stream it to the archiver
which would parse it out.
> I'm also using the custom Message class a lot in the tests.
Can't avoid that with Python 2, I guess, but using Message will be
*so* much less painful with Python 3.
> But I think the main problem is the import of mailman's config
> object in the class that implements the IArchiver interface. I
> don't believe there's another way to get the configuration.
If you need that configuration (which, come to think of it, you
probably do, at least parts of it), you could have a private protocol
for communicating it as metadata (a message header or as metadata in
> And now that I think of it, the archiver interface will be imported
> by Mailman core, and will thus run with a Python3 interpreter. As a
> result, all of KittyStore must at least be Python3 compatible.
In the long run (ie, when nobody who's anybody uses Python 2 at all) I
think everybody would be happier if you refactor to keep KittyStore at
arm's length from Mailman core.