Emmanuel Lecharny wrote:
On 7/22/10 8:23 AM, kalyan wrote:
On Wed, Jul 21, 2010 at 02:50:27PM -0700, Howard Chu wrote:
kalyan wrote:
Hi,
I would like to share some simple idea and find out similar interest. This is about the ldap replication using the existing xmpp network.
Why?
To be frank, i did not think this because there is some serious problem in the existing replication mechanism. But the below might be considered for your question.
<snip/> > Definitely this can't be a default replication method for openldap, but > I am thinking what if I make another directory server to sync to openldap. The best way is probably for this different server to implement RFC 4533. This is what we did at Apache Directory Server allowing us to sync with an OpenLDAP server. It works, it's not *that* complicated. Here is an exemple on how to leverage a Java API implementing this RFC :
http://fanf42.blogspot.com/2010/07/java-ldap-sdk-for-syncrepl-replication.ht...
I would never be one to tell someone not to do whatever they want to do for fun. (My first C programming project was Hack 1.0.2 - there's nothing more fun than hacking on a game...) But if you're going to do something with LDAP you might as well make it useful too. Two small projects that could be completed in a short amount of time: implement a DirSync module for OpenLDAP to replicate from M$AD, and implement a passwordSync module for OpenLDAP with AD.
Inventing new protocols can be fun, but IMO it's only worthwhile if the new protocols are more efficient than existing ones. New protocols need to be more than "twice as good" as existing ones in order to have any chance of adoption. Otherwise it's not worth the effort of transitioning the installed base.
To be frank, i did not think this because there is some serious problem in the existing replication mechanism. But the below might be considered for your question.
- The unchanged attribute is never sent to other server. Always the changed attribute is sent instantly.
Delta-syncrepl already does this.
- The above delta sync does not maintain a changelog, because the changes will be sent immediatly as it happens on a server and unreachable server receives an offline message. Hence no need of a changelog.
Your offline message store becomes a changelog anyway. It's incorrect to say there is no changelog in your scheme.
- N-Way multi-master + multi-salve combination is acheived. You could change the role of a server to master or to slave without the need to change the configuration file and restarting the server.
All of this is already supported using cn=config with no restarts required.
- If its secure environment and if xmpp ports are opened this can be used as proxy as well. But I dont know such environment exist.
It's quite hard to envision an environment where LDAP is needed but is being blocked by a firewall, while the much riskier XMPP protocol is not being blocked.
- I learn openldap and xmpp.
XMPP, and anything else based on XML, is just a gross misuse of SGML. Any network that actually deployed the solution you suggest would quickly be overwhelmed by the traffic, which would be far more heavyweight in carrying LDAP traffic than just plain LDAP.
- Its FUN.
Not everything that's FUN is GOOD.