On Wed, Jul 4, 2012 at 1:01 AM, Claus Folke B.
— quote begin —
Posted via http://www.ruby-forum.com/.
First I’ve just got a tangent/gripe, but when I first looked for a
to use for LDAP use a few years ago, I found the “namespace” confusing:
First take the most popular rubygem (when searching rubygems.org with
term “ldap”). The winner is the “net-ldap” gem. The official homepage is
http://rubyldap.com/" and the code repository is hosted in a Github
repository named “ruby-net-ldap”. The Github repository is hosted under
user “RoryO” according to the metadata from the gem as displayed on
rubygems.org but is hosted under the organization “ruby-ldap” according
the link on the homepage (http://rubyldap.com/).
The “ruby-ldap” Github organization has just the one member, user RoryO,
clearly the project owner has just done some reorganization of the gem.
That’s cool. Plus, the metadata in the gemspec file downloaded as I just
installed the latest version (0.3.1) of the gem appears to be updated
lists the current Github repository URL as the homepage. I guess that
rubygems.org’s metadata is just out of date?
Anyhow, the point of all this is to point out the names that my brain
associates with this library: net-ldap (official gem name and accurate
reference to the name of the class(es) implemented, Net::LDAP), rubyldap
(homepage’s domain), ruby-ldap (w/hyphen, name of organization that owns
official code repository).
In isolation, this wouldn’t be a problem. However, the next most popular
LDAP client gem (I’m skipping ruby-net-ldap which appears to just be the
old, original, net-ldap gem; I’m also skipping activeldap which simply
to wrap another LDAP client library to provide an ActiveRecord-like
interface) – okay, I’m starting this sentence over :). (Clearing
However, the next most popular, unique, LDAP client gem is called
“ruby-ldap”. This is the name that the “net-ldap” gem is using as their
homepage’s domain and Github organization name. So, without being
it is easy to start to get confused.
The “ruby-ldap” gem is at least self-consistent and uses the same name
its RubyForge project name and Github repository name. The docs call the
library “Ruby/LDAP”, this one being a ruby C extension that wraps access
other, existing LDAP libraries.
I guess the proper “name” (I’m referencing the README from the
gem) is “Ruby/LDAP” for the “ruby-ldap” C extension and “Net::LDAP” for
“net-ldap” pure-ruby LDAP-client gem that used to be called
So, yeah. This is a tangential naming gripe. I guess it’s also a
why does “net-ldap” use the “ruby-ldap” name? I understand that some
library authors like to stick the underlying language’s name in the
name for domain name and search/SEO clarity? Hmm.
Anyhow, a little more on-topic, I used the “net-ldap” gem at the last
company I worked for as our email system utilized our central LDAP
and I wanted to centralize all authentication. So, regardless of my
grip/confusion with the name, I’m grateful to the author(s) for their
I understand that for a large enterprise it may be frustrating to not
a more full-fleshed solution. I noted in the discussion thread you
to that someone mentioned that a more ideal implementation might be
EventMachine-based (as well as fully featured). However, the last
from “danabr” in the thread made it appear that others recognize that
isn’t going away but wanted to first focus development efforts on
cleanup (refactoring and adding test coverage).
I also agree that LDAP (and good support for it) is and will continue to
important, even if new projects and systems don’t tend to use it (as one
poster suggested). However, it seems to me that it’s a manpower issue
than anything. Those of us ruby developers who work(ed) doing
“Enterprise-y” coding with ruby often have to make do with whatever tech
currently already available. Only to the degree that we can sell the
of contributing to the Open Source community can we get time to
to and use projects like “net-ldap”. Also, if an existing project works
us (a small enterprise in my case, who’s LDAP-query load was small
that net-ldap worked just fine) we don’t tend to contribute once our
Lastly, though I acknowledge that ActiveDirectory (and by extension
won’t be going away soon, I’d sure like to see (or help work toward) an
alternative to AD/LDAP for user/group identity/policy management. I’m
there are small 3rd-party and/or open source solutions that attempt to
some parts of this but that don’t succeed well enough to displace AD in
sizeable enterprise. I don’t consider Samba any kind of replacement
strategy either since it primarily just tries to compatibly implement
Microsoft’s equivalent software (plus a samba-based NT4-style PDC isn’t
by any means). However, the technology landscape is always changing and
knows what kind of workstations enterprises may deploy in the future and
what opportunities may exists to create alternative policy management
So, yeah. I’d guess a lot of rubyists like to work on something they
consider really forward-thinking (I know I do) as opposed to fleshing
robust libraries for status quo technology. But, on a pragmatic side, we
have to exist and interact with today’s actual real technology, most of
which will still be around for years to come as well. So, there’s room
need to flesh out “net-ldap”'s code base as well as to have people
entirely different views of the underlying technical problem and working
toward a cool new offering. Personally I really dislike LDAP compared to
simpler, schema-less document databases and/or key-value stores and/or
traditional relational databases, depending on the specific need. I
dislike LDAP in principle – I actually like the concept and think a
structured, schema-based, hierarchical, distributed database would be
the thing” for solving some problems. I think I just dislike the
query syntax and the LDIF format. In other words, I dislike details, not
the underlying concept.
Well, my combination of random complaints, thanks, opinions, and
regarding LDAP, ActiveDirectory, and the “net-ldap” gem are over. I
have any conclusions to offer or great, ground-breaking thoughts besides
pointing out the obvious. Hopefully development on “net-ldap” continues
the “manpower” can be found to do so. I currently don’t have an LDAP
so I’m distracted by other projects/goals (though that could change as
moving and consequently need to find a new job).
Good luck solving your own set of problems and finding the best solution
(whether ruby-based or not).