5 ms·

Funny that the L in ldap stands for lightweight, and yet clearly there is interest in a lightweight version of what has become a somewhat bloated protocol.

by will0 2y ago

ivanjermakov 2y ago
Ironically, there is not much "lightweight" in LDAP
- anyfoo 2y ago
  You should have seen X.500.
  - aidenn0 2y ago
    Did X.500 ever get even close to fully implemented?
    - jdougan 2y ago
      Rumour has it that that was logically impossible.
      - kjellsbells 2y ago
        Culturally impossible as well, in the sense thar x.500 expected that every country's national telecom operator would take on the task of handling identity and certs for the population of that country. That said, the US DoD had a pretty good stab at it, and even today in corners of the defense industrial base you can find companies like Isode that still service that niche. To be fair, x.400 messaging and x.500 directory looked pretty smart back in the day when smtp and passwd were the alternatives. It's just that smtp grew up incredibly fast and quickly outstripped the alternative.
        jdougan 2y ago
        I got my start in that era and they only looked smart if you didn't look deeply. Too many options, too many areas where they created a problem and then passed it off to someone else to fix.
- yencabulator 2y ago
  It was simple enough that back in 2002, I could implement a whole client+server LDAP protocol framework from scratch in ~11k lines of Python. That's not horrible. ASN.1 gets a lot of (imho deserved) crap but it's roughly just a bunch of nested TLV (type, length, value) messages, just smeared with a bunch of legacy and a weird definition language. It's not all that different from e.g. Protocol Buffers. Outside of figuring out what context you're in and thus what message type an integer refers to, there's not much that would be "a hard problem" about it.

5 ms·

Funny that the L in ldap stands for lightweight, and yet clearly there is interest in a lightweight version of what has become a somewhat bloated protocol.

by will0 2y ago

Funny that the L in ldap stands for lightweight, and yet clearly there is interest in a lightweight version of what has become a somewhat bloated protocol.

ivanjermakov 2y ago
Ironically, there is not much "lightweight" in LDAP
- anyfoo 2y ago
  You should have seen X.500.
  - aidenn0 2y ago
    Did X.500 ever get even close to fully implemented?
    - jdougan 2y ago
      Rumour has it that that was logically impossible.
      - kjellsbells 2y ago
        Culturally impossible as well, in the sense thar x.500 expected that every country's national telecom operator would take on the task of handling identity and certs for the population of that country. That said, the US DoD had a pretty good stab at it, and even today in corners of the defense industrial base you can find companies like Isode that still service that niche. To be fair, x.400 messaging and x.500 directory looked pretty smart back in the day when smtp and passwd were the alternatives. It's just that smtp grew up incredibly fast and quickly outstripped the alternative.
        jdougan 2y ago
        I got my start in that era and they only looked smart if you didn't look deeply. Too many options, too many areas where they created a problem and then passed it off to someone else to fix.
- yencabulator 2y ago
  It was simple enough that back in 2002, I could implement a whole client+server LDAP protocol framework from scratch in ~11k lines of Python. That's not horrible. ASN.1 gets a lot of (imho deserved) crap but it's roughly just a bunch of nested TLV (type, length, value) messages, just smeared with a bunch of legacy and a weird definition language. It's not all that different from e.g. Protocol Buffers. Outside of figuring out what context you're in and thus what message type an integer refers to, there's not much that would be "a hard problem" about it.