Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-732

apache directory studio don't support OID Macros

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.5.3
    • Fix Version/s: 2.0.0
    • Component/s: studio-schemaeditor
    • Labels:
      None
    • Environment:
      windows XP; Open LDAP 2.4 directory

      Description

      I have 2 attribute that have macro ID : x.y.z:1 and x.y.z:2
      ADS just saw the first one.

      It had been solve on shared project : DIRSHARED-10

        Activity

        Hide
        Emmanuel Lecharny added a comment -

        Keep in mind that OID macro is not an valid form for an OID. OpenLDAP is probably the only LDAP server supporting this.

        Show
        Emmanuel Lecharny added a comment - Keep in mind that OID macro is not an valid form for an OID. OpenLDAP is probably the only LDAP server supporting this.
        Hide
        Francois PICHOUD added a comment -

        I'm not an LDAP expert. I just have a macro OID in my openLDAP.. If ADS will support macro OID, i will use it to manage my openLDAP..

        http://www.openldap.org/doc/admin24/schema.html

        Show
        Francois PICHOUD added a comment - I'm not an LDAP expert. I just have a macro OID in my openLDAP.. If ADS will support macro OID, i will use it to manage my openLDAP.. http://www.openldap.org/doc/admin24/schema.html
        Hide
        Emmanuel Lecharny added a comment -

        Being not an LDAP expert, it would be wise not to use a feature which is very specific to OpenLDAP only.

        I agree that OID macros is a cool feature, but sadly, it's also a guarantee to be a way to get incompatible LDAP data in the long run.

        I'm pretty sure that OpenLDAP peeps have added this feature to ease the management of internal schemas (like configuration or such), but this is only good for people dealing with elements which won' be exposed.

        Use of plain OID (ie, without macros) is frankly a better idea.

        Show
        Emmanuel Lecharny added a comment - Being not an LDAP expert, it would be wise not to use a feature which is very specific to OpenLDAP only. I agree that OID macros is a cool feature, but sadly, it's also a guarantee to be a way to get incompatible LDAP data in the long run. I'm pretty sure that OpenLDAP peeps have added this feature to ease the management of internal schemas (like configuration or such), but this is only good for people dealing with elements which won' be exposed. Use of plain OID (ie, without macros) is frankly a better idea.
        Hide
        Howard Chu added a comment -

        very specific to OpenLDAP only.
        to be a way to get incompatible LDAP data in the long run.
        management of internal schemas (like configuration or such), but this is only
        good for people dealing with elements which won' be exposed.

        I added OID macros to OpenLDAP because the original X.500 spec uses OID
        macros, and I view their omission from LDAP as a bug in the LDAP specs. And
        yes, of course they're actually useful too...


        – Howard Chu
        CTO, Symas Corp. http://www.symas.com
        Director, Highland Sun http://highlandsun.com/hyc/
        Chief Architect, OpenLDAP http://www.openldap.org/project/

        Show
        Howard Chu added a comment - very specific to OpenLDAP only. to be a way to get incompatible LDAP data in the long run. management of internal schemas (like configuration or such), but this is only good for people dealing with elements which won' be exposed. I added OID macros to OpenLDAP because the original X.500 spec uses OID macros, and I view their omission from LDAP as a bug in the LDAP specs. And yes, of course they're actually useful too... – – Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
        Hide
        Clément OUDOT added a comment -

        Actually I'm the one responsible for using OID macros in this exposed schema

        You can see the schema here: http://websvn.ow2.org/filedetails.php?repname=lemonldap&path=%2Ftrunk%2Fmodules%2Flemonldap-ng-common%2Ftools%2Fsso.schema

        Feel free to use it if you need to test the patch.

        Show
        Clément OUDOT added a comment - Actually I'm the one responsible for using OID macros in this exposed schema You can see the schema here: http://websvn.ow2.org/filedetails.php?repname=lemonldap&path=%2Ftrunk%2Fmodules%2Flemonldap-ng-common%2Ftools%2Fsso.schema Feel free to use it if you need to test the patch.
        Hide
        Emmanuel Lecharny added a comment -

        Clément, this is really a bad idea. This schema works only with OpenLDAP.

        It's sad that LDAP specs aren't good enough to support such syntax, and it's even worse that you can't express the SYNTAX using anythong than an OID, but Studio can't take care of such specific cases, because it's a generic Ldap browser, and it must support the common syntax.

        Show
        Emmanuel Lecharny added a comment - Clément, this is really a bad idea. This schema works only with OpenLDAP. It's sad that LDAP specs aren't good enough to support such syntax, and it's even worse that you can't express the SYNTAX using anythong than an OID, but Studio can't take care of such specific cases, because it's a generic Ldap browser, and it must support the common syntax.
        Hide
        Clément OUDOT added a comment -

        Can't we imagine to have an option to allow OID macros, that will be off by default?

        As Howard said, OID macros were present in X500, this can be interesting to manage them in Apache Directory Studio...

        Show
        Clément OUDOT added a comment - Can't we imagine to have an option to allow OID macros, that will be off by default? As Howard said, OID macros were present in X500, this can be interesting to manage them in Apache Directory Studio...
        Hide
        Emmanuel Lecharny added a comment -

        We are going to support OID macros, I'm just saying that users should not use them.

        Rahhh... There are so many thing lacking in LDAP...

        Show
        Emmanuel Lecharny added a comment - We are going to support OID macros, I'm just saying that users should not use them. Rahhh... There are so many thing lacking in LDAP...
        Hide
        Clément OUDOT added a comment -

        Ok!

        I agree that if OID macros are not really defined in the standard, they should not be used.

        Morever, it would be great to have a standard schema representation, so an application can provide a schema file that could be inserted in any standard LDAP directories. Do you know if some work has been done on this?

        Show
        Clément OUDOT added a comment - Ok! I agree that if OID macros are not really defined in the standard, they should not be used. Morever, it would be great to have a standard schema representation, so an application can provide a schema file that could be inserted in any standard LDAP directories. Do you know if some work has been done on this?
        Hide
        Emmanuel Lecharny added a comment -

        We do have a common schema representation, the one which is described in RFC 4512. Every schema manipulation is using the objects (AT, OC, etc) described in this RFC. Then it's possible to inject all those elements in any compliant LDAP server, which obvioulsy include OpenLDAP and ApacheDS as of today, most certainly OpenDS/DJ (to be double checked) and probably some other LDAP server (but we don't have licenses to test those guys).

        So, yes, in the really near future, it should work.

        Show
        Emmanuel Lecharny added a comment - We do have a common schema representation, the one which is described in RFC 4512. Every schema manipulation is using the objects (AT, OC, etc) described in this RFC. Then it's possible to inject all those elements in any compliant LDAP server, which obvioulsy include OpenLDAP and ApacheDS as of today, most certainly OpenDS/DJ (to be double checked) and probably some other LDAP server (but we don't have licenses to test those guys). So, yes, in the really near future, it should work.

          People

          • Assignee:
            Unassigned
            Reporter:
            Francois PICHOUD
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development