[Calendarserver-discuss] imip-agent 0.2 (iMIP capabilities for mail servers)

[Paul Boddie]

On Thursday 26. January 2017 13.55.02 Jonas Smedegaard wrote:
> 
> Quoting Paul Boddie (2016-04-26 21:50:47)
> 
> > Since there's been some discussion about it on this list, I thought I
> > would announce a new version of imip-agent: an extension for existing
> > mail systems (such as Exim and Postfix) providing extra support for
> > calendaring and scheduling using the iCalendar, iMIP and iTIP standards.
> 
> I finally put a bit of attention to imip-agent againg, and 0.2 is now in
> Debian experimental.

Great! Thanks for spending some time on it! :-)

> Suggestion: Adapt imiptools/stores/__init__.py to only try import
> imiptools.stores.database and run stores.update.  It seems that change
> would make it possible to package imiptools/stores/database separately
> as an optional addon - avoiding SQL library dependences in core
> packages.

I'll take a look at that. The database functionality is supposed to be 
optional, of course, so it makes sense to explore ways of decoupling it from 
the basic functionality. One thing I've done for the scheduling extensions is 
to have a tool that explicitly configures them...

tools/update_scheduling_modules.py

...which builds the manifest for those extensions:

imiptools/handlers/scheduling/manifest.py

This might seem inelegant when Python allows conditional importing and all 
sorts of other tricks, but I wanted a separation between the configuration of 
the software and what it does when it runs. When the packaging system is 
supposed to take care of such things, you don't then want the software failing 
because it tries to take on the same job at run-time.

The quick fix here is to do a conditional import, but it does make me think 
that I could provide a similar configuration mechanism for storage extensions 
that also has a manifest file. New storage extension packages would invoke a 
tool to update the manifest.

> Question: is imiptools/config.py meant to be only internal defaults, or
> user configurable?

It is supposed to be user-configurable and maybe the documentation should be 
clearer about that. The tools/install.sh script copies it to /etc/imip-agent 
(or equivalent) and then makes a symbolic link to it from the normal library 
location. I'm not sure whether that's the right thing to do in Debian, though.

> I hope to have more time in the Spring to explore imip-agent, so if you
> have improvements please consider making another release. :-)

I did do some more work on it last year, but various other things prevented me 
from dedicating much time to it, unfortunately. However, I'll certainly try 
and complete some of the things I have been working on.

Thanks for your continuing interest in the software!

Paul