the autocreate feature (Cyrus IMAPd 2.3.7 Released)

[Christos Soulios]

Hi all.

I have seen this issue come up several times in the info-cyrus list. The 
answer to the question 'why isn't autocreate included in the cyrus 
distribution' is 'because it does not support the murder architecture'. 
The CMU developers do very well not to accept a patch that does not work 
with all possible configurations, since if they did otherwise, that 
would lead to a maintance nightmare. However, as mentioned before, the 
patch existed before murder was released, but no one knows why it was 
not included then.

Other than murder support, the autocreate patch is perfectly compatible 
and well tested with unix hierarchy separator, alternate namespaces and 
virtual domains. I am pretty much sure that it works with cyrus 
replication, although it is not tested yet and I have no reports by 
anyone playing with autocreate and replication code. All these are 
documented in the README.autocreate file distributed with the patch. (It 
can also be found here: 
http://email.uoa.gr/projects/cyrus/autocreate/README.autocreate-cyrus-2.3)

So, anyone who does not deploy a murder setup can use the autocreate patch.

The next question that comes to everyone is 'why don't you implement 
murder support for the autocreate patch?'. The answer is 'because it is 
not so easy to do it'. Actually, implementing such a feature for a 
murder environment is not simply a matter of writing some code. Serious 
design decisions have to be taken.

For example:
  - If a client contacts a front end, who decides in which backend 
should the mailbox be created?
- How should the frontend iniate a mailbox creation procedure to a 
specified backend?
- What should happen in every different murder scenario (standard, 
unified, replicated)? Especially when some architectures like replicated 
murder are not so well tested yet.
- The MUPDATE protocol (http://www.ietf.org/rfc/rfc3656.txt) may need 
some extentions/modifications to support the autocreate patch. Modifying 
an IETF RFC requires responsible decisions that can't be taken by a 
single developer.

One may understand, that there are two approaches to solving the above 
issues. The 'quick and dirty hack' approach, which would have some 
config variables for some of the above decisions. A patch like that 
could be produced in a few weeks time.

On the other hand, there could be a well designed, scalable solution 
that would have some inteligence (ie different groups of user mailboxes 
are created in different backends, the mupdate server performs load 
balancing in mailbox creation).

Since we, at the University of Athens do not use a murder enviroment and 
it is not one of our priorities either, we would go on implementing it 
only if the final result would be a well designed, extensible piece of 
code that would lead to integrating the patch into the main distribution.

In the past there were some efforts in the cyrus-devel list to start 
discussing an initial approach for the support of murder by the patch. 
However, they did not lead anywhere, as the patch was not within the 
priorities of the CMU developers. See threads:
http://email.uoa.gr/archive/message.php?mailbox=Software.cyrus-devel&searchterm=autocreate&msg=1048
http://email.uoa.gr/archive/message.php?mailbox=Software.cyrus-devel&searchterm=autocreate&msg=1585

Ever since this issue comes up from time to time but no progress has 
been made.

I hope this email answers some of the questions asked in this thread. 
However, what I want to ask is the following: What happens next? Since 
both the CMU and the UOA developers are too busy with their own 
priorities, can the cyrus community make some development work? Are 
there any people determined to work as a team and do some work on cyrus? 
And by this I mean, a true development cycle, which requires collecting 
all feature requests, prioritising them, presenting a decent feature 
roadmap, discussing design of the featues, distributing development 
responsibilities and finally making sure that the patches are pushed 
into the main distribution.

Of course, that requires an active community that is supported and 
encouraged by CMU, but above all it requires willing with programming 
skills and will to help.This would make cyrus work as lots of other 
opensource projects and would push the delivered product quality really 
high. That should be a priority for all cyrus developers, users.

Lastly, in the past there were some efforts to create this sort of 
community, starting with work in the also much discussed cyrus 
documentation via the cyrus wiki. However, this effort did not evolve 
and cyrus is still poorly documented.

Cheers,
Christos