On 03/03/12 19:42, Kartik Subbarao wrote:
On 03/03/2012 08:11 AM, Daniel Pocock wrote:
On 01/03/12 22:17, Kartik Subbarao wrote:
I'm integrating OpenLDAP as an LDAP Directory component in the open source Collabograte project that I recently announced:
I think this is interesting and very worthwhile. There are similar projects like FusionForge, some of them use OpenLDAP. Can you elaborate on what makes Collabograte distinctive from those other alternatives?
The primary audience for Collabograte is IT integrators who want to assemble their own custom services from individual collaboration components that they choose. Collabograte helps them with the heavy lifting of integration -- connecting the dots between these different components. For example, in the role of "LDAP Directory Component", Collabograte can provide configurations for a number of LDAP servers. OpenLDAP is the first one that it supports, but there is no restriction on the products that can be supported. The same is true for any other category of component. So down the line, Collabograte might support 5 different OSes, 4 different LDAP servers, 3 different Wikis, etc.
It is interesting that you are posting about this on the OpenLDAP list, I also came here just recently with similar aims in mind:
https://sourceforge.net/mailarchive/message.php?msg_id=28879194
One of the challenges I've come across is deciding how to reconcile the user ID naming conventions, e.g.
- Moin (and some other wikis) have a convention of WikiNames, e.g. DanielPocock, so that you can have a `user' page such as http://wiki.example.org/DanielPocock
- some apps (e.g. bugzilla, git/gitosis, mailman, sympa) are using email address
- for some apps (e.g. Drupal) it is common to use OpenID, but also have an `alias' on the site itself, such as daniel.pocock, dpocock (or my favourite, sneaky_troll)
- and some apps (like granting UNIX access) require a short and concise user ID like dpocock
I'd be interested in any comments you have on that subject: you anticipate asking users to use all of these IDs? Or just go for the lowest common denominator (e.g. an ID like dpocock) and an email address?
I will have a look over the architecture of your solution. I had imagined implementing some kind of workflow system (maybe using Apache Camel, for example) that would take input events such as `new user' or `password change' and would then asynchronously propagate the event to all the components.
My objective in doing this, however, is actually to support another project, http://www.lumicall.org http://www.sip5060.net and http://www.opentelecoms.org - basically, I'm building a collection of sites to facilitate open, secure, federated SIP, and I'm looking at how to integrate the collaborative tools to support them, rather than just dumping it all on sourceforge or github.