On Wed, Jul 4, 2012 at 1:01 AM, Claus Folke B.
[email protected]wrote:
— quote begin —
–
Posted via http://www.ruby-forum.com/.
First I’ve just got a tangent/gripe, but when I first looked for a
library
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
the
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
the
user “RoryO” according to the metadata from the gem as displayed on
rubygems.org but is hosted under the organization “ruby-ldap” according
to
the link on the homepage (http://rubyldap.com/).
The “ruby-ldap” Github organization has just the one member, user RoryO,
so
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
and
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
has
to wrap another LDAP client library to provide an ActiveRecord-like
interface) – okay, I’m starting this sentence over :). (Clearing
throat)…
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
careful,
it is easy to start to get confused.
The “ruby-ldap” gem is at least self-consistent and uses the same name
for
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
to
other, existing LDAP libraries.
I guess the proper “name” (I’m referencing the README from the
activeldap
gem) is “Ruby/LDAP” for the “ruby-ldap” C extension and “Net::LDAP” for
the
“net-ldap” pure-ruby LDAP-client gem that used to be called
“ruby-net-ldap”.
So, yeah. This is a tangential naming gripe. I guess it’s also a
question:
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
library
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
database
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
work.
I understand that for a large enterprise it may be frustrating to not
have
a more full-fleshed solution. I noted in the discussion thread you
linked
to that someone mentioned that a more ideal implementation might be
EventMachine-based (as well as fully featured). However, the last
message
from “danabr” in the thread made it appear that others recognize that
LDAP
isn’t going away but wanted to first focus development efforts on
project
cleanup (refactoring and adding test coverage).
I also agree that LDAP (and good support for it) is and will continue to
be
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
more
than anything. Those of us ruby developers who work(ed) doing
“Enterprise-y” coding with ruby often have to make do with whatever tech
is
currently already available. Only to the degree that we can sell the
idea
of contributing to the Open Source community can we get time to
contribute
to and use projects like “net-ldap”. Also, if an existing project works
for
us (a small enterprise in my case, who’s LDAP-query load was small
enough
that net-ldap worked just fine) we don’t tend to contribute once our
itch
is scratched.
Lastly, though I acknowledge that ActiveDirectory (and by extension
LDAP)
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
sure
there are small 3rd-party and/or open source solutions that attempt to
do
some parts of this but that don’t succeed well enough to displace AD in
any
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
AD
by any means). However, the technology landscape is always changing and
who
knows what kind of workstations enterprises may deploy in the future and
what opportunities may exists to create alternative policy management
frameworks.
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
out
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
and
need to flesh out “net-ldap”'s code base as well as to have people
taking
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
don’t
dislike LDAP in principle – I actually like the concept and think a
structured, schema-based, hierarchical, distributed database would be
“just
the thing” for solving some problems. I think I just dislike the
underlying
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
comments
regarding LDAP, ActiveDirectory, and the “net-ldap” gem are over. I
don’t
have any conclusions to offer or great, ground-breaking thoughts besides
pointing out the obvious. Hopefully development on “net-ldap” continues
and
the “manpower” can be found to do so. I currently don’t have an LDAP
itch
so I’m distracted by other projects/goals (though that could change as
I’m
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).