On Wednesday 17. June 2015 19.27.45 Simo wrote:
On Wed, 2015-06-17 at 18:27 +0200, Paul Boddie wrote:
It's quite possible to support other systems (Exim for mail, OpenLDAP for directory services, Dovecot for mailboxes, and so on), and there is a demand for it, but it hasn't happened within Kolab itself. All I ask is that you consider why this is, other than stating that it is difficult.
[...]
In FreeIPA too we settled on a specific directory technology (which totally coincidentally happens to be 389ds), and a specific Kerberos implementation and DNS implementation and so on. In theory we can support multiple implementations, but in practice we can't, and the reason is that the glue that makes all this components work together such that they actually work and provide a usable experience to users is more nuanced than you may think, and goes beyond the mere "standard" protocols.
It can be difficult, certainly. First of all, you have to understand what the solution is actually doing, and here it helps to have it documented. Then, you need to understand what mechanisms it is using to do it, and whether what you want to use supports those mechanisms. I accept that there are things that Kolab components use from various solutions that other solutions may not provide, or at least do not provide in exactly the same way. (From memory, I can think of some ACL-related stuff in the directory support, and things like metadata attributes in the mailbox support.)
It is already hard enough for a dedicated team to stay on top of the ever changing (and improving) underlying components that have been chosen. Adding the ability to glue together completely different implementations (with different bugs and quirks, different configuration methods and options, and different features-sets) is a whole 'nother level.
As sad as it may be, products that "integrate" existing components into a cohesive solution must choose a target and develop against it, and take the best they can from the components they choose.
Going from a specialised solution that works to something more general may not buy the implementers anything, and there isn't always a demand for it, either. I can accept that.
It is possible that in time the underlying components evolve in such a way that the chosen one is not the most ideal anymore. In those cases it is possible to swap for another, but again it usually means rewriting the glue to deal with this new component and ditch the old one.
Well, Kolab was, at the last point at which I checked, heavily tied to Cyrus and 389-ds in that swapping them out for other things requires a degree of component rewriting, which I did actually attempt, but it involves going through a fair amount of code spread over many places within at least one server component. I mentioned monolithic before now, and it always seems to get a laugh, but I am reminded of the monolithic kernel versus microkernel debate when I see such modularity issues.
(Of course, in this age of "patch gymnastics" and the magic merge, the topic of modularity doesn't get as much attention as it used to, but that's another story.)
This is the life of the 'integrator', flexibility is, somewhat, sacrificed in the name of usability, maintainability, deploy-ability and stability, all features most users value a great deal, whether they come from the community or as paying customers.
Sure, no-one is against the virtues you mention. I was mostly taking issue with the mechanism through which such things might come from the community, because there was actually an interest in doing the tiresome work of supporting other systems and components, and doing so in a way that might actually improve the robustness of the software (which can also be a well- understood benefit of modularity). You have undoubtedly read what I have had to say about that.
Paul
P.S. Interestingly, there was someone asking a few times about Kolab working together with FreeIPA. Maybe you could give them some advice about it because they couldn't seem to get it to work last time I looked.