Diskussion:Lightweight Directory Access Protocol

message: "LDAP agiert als Frontend zu hierarchischen Datenbanken.". Unsinn: LDAP ist ein Protokoll, kein Frontend. Typische Implementierungen von Verzeichnisdiensten, die LDAP als Protokoll unterstützen, verwenden zur Datenhaltung entweder eine Textdatei (passwd) oder Berkeley DB. Und Berkeley DB ist keine hierarchische Datenbank, sondern ein flat file mit Zugriff über eine Hash-Tabelle. Ob das objekt-orientierte, hierarchische Datenmodell von X.500 (das LDAP adaptiert) für einen Verzeichnisdienst sinnvoll ist, darüber kann sicher streiten - man sollte das aber bei X.500 diskutieren. Das sich relationale Datenbanken mit hierarchischen Datenstrukturen (Stücklisten, Stammbäumen, usw.) schwer tun, ist nicht diesen Datenstrukturen anzulasten, sondern eine Schwäche des relationalen Modells. --Jost Riedel (Diskussion) 10:02, 1. Dez. 2012 (CET)
replies: text: Die ursprüngliche Aussage ist nicht richtig, da stimme ich zu. Mir geht es eher um die Aussage zur Berkeley DB, konkret im Zusammenhang mit OpenLDAP. Kommt es dabei nicht auf das verwendete Backend an? LMDB und HDB ist laut OpenLDAP Dokumentation hierarchisch. Bei HDB steht geschrieben "[...] uses hierarchical database layout [...]". Siehe: http://www.openldap.org/doc/admin24/backends.html Mkriesten (Diskussion) 17:57, 2. Feb. 2014 (CET)
thread_title:  LDAP und Datenbankmodelle 

message: Folgenden Satz habe ich gelöscht:
Im theoretischen Vergleich mit einer relationalen Datenbank ist LDAP aufgrund seiner zugrundeliegenden hierarchischen Datenhaltung auf den ersten Blick haushoch unterlegen. Mit Vorkenntnissen relationaler Datenhaltung mag LDAP sogar zunächst als anachronistisch angesehen werden.
Das ist eine subjektive und faktisch nicht belegbare Einschätzung. 
Welche Kriterien wendet man an, um zu zeigen das "LDAP haushoch unterlegen" ist? 
Wenig enzyklopädisch, trägt zum Verständnis nix bei, daher *plonk*
Folgenden Satz habe ich gelöscht:
Metadirectories und die damit verbundenen Mechanismen versuchen, diese Probleme zu mildern (können sie aber nicht lösen, da die Probleme strukturell sind).
Der Begriff Metadirectories wird verwendet aber nicht erklärt. 
Auch halte ich den Satz für sachlich falsch: Metadirectories dienen dazu einen standardisierten Zugriff auf unterschiedliche Datenquellen zu bereitzustellen.
 
Ich habe den Unterabschnitt "Keine erste Normalform, sondern Strings mit Format" gelöscht. Die Verschlüssellung von Userpassworten ist eine Option von LDAP, kein MUSS. Man wird diese Option nur dort einsetzen, wo sie Sinn macht, eine Abfrage über
Userpasswörter ist völlig unsinnig.  
Ich habe den Unterabschnitt "DN" nicht stabil im Abschnitt "Schwächen von LDAP"
gelöscht. Bei dem angegebenen Beispiel gibt der Autor (wohl unfreiwillig) eher
ein Beispiel für schlechtes Design, anstatt für eine "Konstruktionsschwäche" 
eines etablierten Protokolls.
Aus genau den vom Autor beschriebenen Gründen wird man in einem Verzeichnis
bei den Personenobjekten auflisten, welche Mailinglisten sie abonniert haben,
und nicht umgekehrt! Die Abonnentenliste der Mailingadresse erhält man dann
über eine Abfrage!
Ich habe mir mal erlaubt, den letzten Abschnitt "Schwächen von LDAP"
zu löschen weil m.E nicht enzyklopädisch genug:
Volkommen gelöscht hab ich folgende:
 == Schwächen von LDAP ==
 Zu praktisch relevanten Schwächen von LDAP gehört leider eine allgemein schlechte oder schwer verständliche Dokumentation (betrifft gleichermaßen LDAP-Protokoll, LDAP-Server, LDAP-Clients und LDAP APIs), umständlich und meist extrem komplex zu verwendende APIs (Stichwort: Java JNDI) und allgemein wenig Erfahrung bei Programmierern. Aus diesen Schwächen resultieren viele LDAP-Praxis-Probleme, die zu einem eher schlechten Ruf von LDAP beitragen, weil Applikationsdesigner Anforderungen stellen, die sich mit LDAP nicht gut abbilden lassen und weil Programmierer LDAP-APIs häufig unsauber oder unperformant integrieren.
* Es gibt hervorragende Dokumentation zu LDAP, die dem Schreiber dieser Zeilen
: möglicherweise nicht bekannt war
* Der Schreiber behauptet die Dokumentation **aller** LDAP Apis sei schlecht.
: Das ist subjektiv geurteilt, und ich wage zu bezweifeln dass Schreiber *alle*
: LDAP APIS kennt (JNDI, JavaLDAP, PHP, Pyton, Net::LDAP, .....usw )
* Der Schreiber postulierte einen hypothetischen nicht belegbaren Sachverhalt:
: "..Applikationsdesigner Anforderungen stellen, die sich mit LDAP nicht gut 
: abbilden lassen" 
: *plonk* 
Für den Laien (wenn dieser LDAP z.B. in Thunderbird liest) vielleicht erklären, was man prinzipiell damit anstellen kann. Ist wahrscheinlich zu allgemein und sehr schwer zu fassen  - aber vielleicht kann es trotzdem gelingen. 
Weblink zeigt auf eine leere Seite, ändert sich das noch ? Ansonsten lösche ich den Link 
der weblink "OpenLDAP, GPL Version eines LDAP-Verzeichnisses" is glaubich falsch. OpenLDAP steht unter der
OpenLDAP Public License. siehe: http://www.openldap.org/devel/cvsweb.cgi
das is kein GPL.
Vielleicht kann mal jemand, der davon Ahnung hat, den Link unter 'Funktionsweise' zu dem Thema 'Schema' (Schemata) anpassen. --213.168.102.131 09:27, 11. Jan 2005 (CET)
thread_title:  Überarbeitung von ?? 

message: Kann jemand die genaue Jahreszahl raussuchen, wann LDAP jetzt entwickelt wurde? Es gab zwei Ideen im Text, einmal 199 und einmal 1993 - gefunden habe ich aber zu beiden Daten nichts, weswegen ich es erst mal rausgenommen habe --Liquidat 12:36, 28. Jun 2005 (CEST)
replies: text: hmm, http://www.ietf.org/rfc/rfc1487.txt - das ist offenbar das erste RFC für LDAP, ist vom Juli 93. Entwickelt wurde wahrscheinlich schon vorher... Kruemelmo 13:45, 28. Jun 2005 (CEST)
thread_title:  Jahreszahl 

message: Hallo,
die Angaben unter dem Baumstruktur-Bild scheinen IMHO ohne mich näher mit LDAP beschäftigt zu haben, teilweise falsch, da im Knoten andere Werte stehen als in den Attributen darunter. Also Copy&Paste-Fehler? Kann da mal jemand bitte darüberschauen und das überprüfen?
212.202.71.51 09:55, 15. Aug. 2007 (CEST)
thread_title:  Baumstruktur-Bild 

message: In den Weblinks wird OpenLDAP als Referenzimplementierung ausgegeben. Quellen dafür konnte ich nicht finden.
De facto referenzimplementierung?
In http://www.openldap.org/lists/openldap-software/200206/msg00453.html wird behauptet, dass der Standard durch den RFC und nicht durch eine Implementierung definiert ist. Kann das jemand fixen? 
--Self 13:09, 4. Okt. 2008 (CEST)
thread_title:  Referenzimplementierung? 

message: Das "Directory Access Protocol" auf LDAP verweist ist falsch DAP ungleich LDAP. --Bkmzde 09:47, 29. Mär. 2010 (CEST)
thread_title:  falscher "Directory Access Protocol"-Redirect 

message: Hallo,
ich finde, dieser Bezug müsste noch in den Artikel, da man sich fragen könnte, warum man denn keine Datenbank verwendet, um Nutzerdaten oder Konfigurationsdaten zu halten und abfragbar zu machen. Ein Abschnitt darüber wäre schön und sinnvoll, soweit ich sehe.
mfg Captainsurak 17:35, 26. Aug. 2010 (CEST)
thread_title:  Abgrenzung zu Datenbanken 

message: Der Artikel ist im Abschnitt LDAP-Verzeichnis schlecht geschrieben. Die Bezeichner wie bspw. ou und o werden 6 Abschnitte lang verwendet, bis sie dann erst im 7. Abschnitt nach deren ersten Erwähnung erstmals erklärt werden. Als Leser kann man so dem Artikel nur schwer folgen, weil einem gar nicht klar ist, was oe und o bedeuten soll. Die Erklärung wird erst weiter unten aufgeführt. --134.3.83.235 16:00, 28. Dez. 2018 (CET)
thread_title:  Die Typenbezeichnungen der Attribute sollten vor ihrer Verwendung erklärt werden 

message: Da steht bspw. "Mit der bind-Direktive vermittelt man dem Directory-Server über eine dn, wer den Zugriff durchführen möchte (entweder anonym, per Passwort-Authentifizierung oder anders)
baseDN" Wofür steht denn dn? Was soll das sein? Etwa domain name? Bei gutem Deutsch werden Abkürzungen vor ihrer Verwendung erst einmal ausgeschrieben hingeschrieben, die bloße Verwendung von nicht geläufigen Abkürzungen und dn ist ganz gewiss keine geläufige Abkürzung, IP dagegen schon, ohne diese mindestens einmal am Anfang auszuschreiben ist Murks und wird einer Enzyklopädie nicht gerecht. --134.3.83.235 16:14, 28. Dez. 2018 (CET)
thread_title:  Im Abschnitt Protokoll sieht es nicht viel besser aus