History of LDAPContactsPackage

Feasibility Study

There have been requests for an LDAP compatible Contacts address book, which was started by lsces. I've provided an overview of LDAPCompatibility here.

Analysis and Specifications - due 17 July 2005

Requirements for v1.0 are:

• Data model compatibility with LDAP ie single contact can have unlimited multiple attributes.
• Optional auto-update to/from LDAP server (synchronised SQL table storage)
• Optional direct LDAP communications (minimal SQL table storage)
• If feasible, sub-class LibertyStorage to allow LDAP as a minimal storage mechanism (?)
• LibertyPackage compliant where possible
• Provide plugins for LibertyContent to access LDAP and/or Contact records

Design, Documentation and Quality Assurance

TODO

Development

TODO

Systems Implementation

TODO

Systems Maintenance

TODO

Resources

This is an interesting interview that talks about LDAP vs XML, and the use of XML for CMS systems

• http://www.zope-europe.org/articles/200506/johnmerrells

These talk about using XML with LDAP

• http://memberwebs.com/nielsen/code/ldapxml/
• http://whitepapers.zdnet.com/abstract.aspx?promo=50002&docid=110834
• http://www.infoloom.com/gcaconfs/WEB/TOC/t0285_.HTM

Definitions

None as yet

Feasibility Study

I have the requirement for an LDAP compatible Contacts address book. I've provided an overview of LDAPCompatibility here.

Analysis and Specifications v1.0

The initial design will be based upon LibertyForms - SDLC and will act as an add-on to provide the following.

Requirements for v1.0 are:

• Data field compatibility with LDAP ie single contact can have unlimited multiple occurance of attributes - wolff_borg
  • Optional auto-update to/from LDAP server (synchronised LibertyContent storage) - wolff_borg
  • Optional direct LDAP communications (minimal LibertyContent storage) - wolff_borg
  • If feasible, sub-class LibertyStorage to allow LDAP as a minimal storage mechanism - wolff_borg
• Provide plugins for LibertyContent to access Contact records - wolff_borg

Design, Documentation and Quality Assurance

TODO

Data Model

Not a very good diagram, but a start in understanding how this all fits together:{CODE()} UI Form -> LibertyContent (data/type array) -> LDAP server (LDIF - optional component){CODE}

LDIF - LDAP Data Interchange Format

Data coming from an LDAP server would look something like this:{CODE()}dn: cn=Stephan Borg,ou=people,o=bitweaver
cn: Stephan Borg
givenName: Stephan
sn: Borg
mobile: 1234 567 890
uid: wolff_borg
o: Bitweaver
mail: me@home.com
mail: me@home2.com
calFBURL: http://bitweaver.org/fb/wolff_borg.ifb
objectClass: top
objectClass: inetOrgPerson
objectClass: person
objectClass: organizationalPerson
objectClass: calEntry{CODE}

LibertContent

Once imported into the class, the data would be stored in an array. I have tried to keep the format inline with the array format used by the LDAP PHP commands.{CODE()}array(
"cn" => "Stephan Borg",
"givenName" => "Stephan",
"sn" => "Borg",
"mobile" => "1234 567 890",
"uid" => "wolff_borg",
"o" => "Bitweaver",
"mail" => array(
"me@home.com",
"me@home2.com"
),
"calFBURL" => "http://bitweaver.org/fb/wolff_borg.ifb",
);{CODE}

Development

TODO

Systems Implementation

TODO

Systems Maintenance

Package Maintainer Team

See Package Maintainer Teams for details and requirements of each of the roles.

• Steering Committee
  • wolff_borg
• Key Users (Creation of user acceptance procedures)
  • wolff_borg
• Training (User documentation and tutorials)
  • volunteers?
• Quality Assurance (Ensure package functionality from the lowest API levels using TestingSuites)
  • wolff_borg
• Developers (Try and keep the data and presentation code segregated(:eek:))
  • wolff_borg
  • StarRider (Forms & Plugins)
• Support (Upgrade/migration paths and support)
  • wolff_borg