Changes between Version 5 and Version 6 of Document/Development/Design/LdapBackend

Timestamp:

10/14/08 12:18:59 (5 years ago)

Author:

jgarcia@… (IP: 88.26.177.14)

Comment:

information for both ldap #1 and ldap #2

Document/Development/Design/LdapBackend

@@ -37 +37 @@
  * ''More stuff to come...''
 
+----
+
 == Work in progress ==
+
+=== Ldap !#1 ===
+__Relationship betwen ldap Type <=> Ebox::Type__
+
+ * Templates to create ''attributetype'' of some concrete SYNTAX. 
+   * Definition
+{{{
+AttributeTypeDescription = "(" whsp
+   numericoid whsp     ; AttributeType identifier
+ [ "NAME" qdescrs ]             ; name used in AttributeType
+ [ "DESC" qdstring ]            ; description
+ [ "OBSOLETE" whsp ]
+ [ "SUP" woid ]                 ; derived from this other
+                                ; AttributeType
+ [ "EQUALITY" woid              ; Matching Rule name
+ [ "ORDERING" woid              ; Matching Rule name
+ [ "SUBSTR" woid ]              ; Matching Rule name
+ [ "SYNTAX" whsp noidlen whsp ] ; Syntax OID
+ [ "SINGLE-VALUE" whsp ]        ; default multi-valued
+ [ "COLLECTIVE" whsp ]          ; default not collective
+ [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
+ [ "USAGE" whsp AttributeUsage ]; default userApplications
+ whsp ")"
+}}}
+     * Matching rules 
+       * Needed for:
+         * EQUALITY neccesary for =
+         * ORDERING neccesary for <, >
+         * SUBSTR neccesary for * (different of ~= operator)
+       * Get all of them
+         * ldapsearch -H ldap://localhost -x -s base -b "cn=subschema" "(objectclass=*)" matchingrules
+         * http://tools.ietf.org/html/rfc2252#section-4.5
+     * Syntaxes
+       * Get all of them
+         * ldapsearch -H ldap://localhost -x -s base -b "cn=subschema" "(objectclass=*)" ldapsyntaxes
+         * http://tools.ietf.org/html/rfc2252#section-6
+   * Types supported
+     * Boolean
+     * String
+     * Integer
+     * Float
+     * Datetime
+   * Templates
+{{{
+attributetype ( __OID__ NAME '__NAME__'
+ ___OPTIONS___
+)
+
+OPTIONS depends on which type we want to represent:
+
+Boolean
+  EQUALITY booleanMatch
+  SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+
+String (DirectoryString) UTF-8 encoding of ISO-10646 (Unicode)
+  EQUALITY caseIgnoreMatch
+  SUBSTR caseIgnoreSubstringsMatch
+  ORDERING caseIgnoreOrderingMatch
+  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{__MAX__}
+
+Integer
+  EQUALITY integerMatch
+  ORDERING integerOrderingMatch
+  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+
+
+Float
+  There is no standard for saving them, so save them as String
+
+Datetime
+    EQUALITY generalizedTimeMatch
+    ORDERING generalizedTimeOrderingMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+}}}
+ * Every Ebox's Types has a method (see Ldap #2 ) description() with a hash with tuples name => type
+ * A function "somewhere" gets a EBox::Type (and a Module and Model name) and generates the attributetype schema definitions
+   * For types that have more than one field (e.g. PortRange) the function generates more than one attributetype
+   * Special cases will be:
+     * Composite: do nothing
+     * HasMany: No need for declare an attributetype, a hasmany field in a model, means a eboxModel as a may-attribute
+
+=== Ldap !#2 ===
+__''New Types? Automatic or manual generation''__
+
+Every ''EBox::Type'' has to implement a ''description()'' method. With this information (how the type need to be stored), we'll be able to generate schemas for every possible type created
+
+e.g.:
+{{{
+package EBox::Type::Boolean;
+
+sub description() {
+    my $self = shift;
+    return { 
+        $self->fieldName() => EBox::Ldap::Types::Boolean 
+    };
+}
+}}}
+{{{
+package EBox::Type::Port;
+
+sub description() {
+    my $self = shift;
+    return {
+        'initial' => EBox::Ldap::Types::Integer,
+        'end'     => EBox::Ldap::Types::Integer,
+        'type'    => EBox::Ldap::Types::String
+    };
+}
+}}}
+
+=== Ldap !#3 ===
+
+=== Ldap !#4 ===
+
+=== Ldap !#5 ===
+
+=== Ldap !#6 ===
+
+=== Ldap !#7 ===
+
+
+----
 
 == Guides and stuff ==