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
----
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
