Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
Domesday/Directory Design: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(Created page with "The current plan is to make the back-end of Domesday an LDAP directory. This page documents the requirements for the schema etc. A lot of the requirements revolve around the [Do...") |
No edit summary |
||
| Line 1: | Line 1: | ||
The current plan is to make the back-end of Domesday an LDAP directory. This page documents the requirements for the schema etc. | The current plan is to make the back-end of Domesday an LDAP directory. This page documents the requirements for the schema etc. | ||
A lot of the requirements revolve around the [Domesday#Tagging tagging system]. | A lot of the requirements revolve around the [[Domesday#Tagging|tagging system]]; familiarity with that is essential for considering this design question. | ||
===Attributes=== | ===Attributes=== | ||
See [Domesday#Data_Fields the main Domesday page] for a list of data items to be stored, which has been annotated with possible attribute names from inetOrgPerson or elsewhere. The only data which probably cannot be stored in a single entry for a person, or subentries of it in the case of the various service IDs, is the tagging data. | See [[Domesday#Data_Fields|the main Domesday page]] for a list of data items to be stored, which has been annotated with possible attribute names from inetOrgPerson or elsewhere. The only data which probably cannot be stored in a single entry for a person, or subentries of it in the case of the various service IDs, is the tagging data. | ||
We will need an additional auxiliary objectClass for our own attributes, such as "Call Me" and "Year Started". | We will need an additional auxiliary objectClass for our own attributes, such as "Call Me" and "Year Started". | ||