[turba] __type attribute for LDAP

[eculp at encontacto.net]

Mensaje citado por Adam Tauno Williams <adam at morrison-ind.com>:

<snip>
| 
| Ok.  I'm assuming that .16 and .17 are the next available object OID values
| by
| looking at the distributed horde.schema file.

Adam,

Thanks, for taking the time to do this and explain the options.
There is an issue here that you may not know and I'm not sure everyone
has been doing the same way.  In horde/scripts/ldap there is a program
to generate a new schema dynamically.  This means that the OID values,
AFAIK, have never been constant.  I just tested the program and there
are now 35 "prefs" that I'm not sure will be used.  I would suggest 
that these two attributetypes start at 201 to leave space for new
applications.  Would that make sense?  I would assume that we should
not be changing the OID value.  Do you agree?

| 
| attributetype ( 1.3.6.1.4.1.13040.1.2.4.16
|         NAME 'turbaMembers'
|         DESC 'Members of a Turba Group'
|         EQUALITY caseIgnoreIA5Match
|         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{4000} )
| 
| I made it "{4000}" since that is the size of the members field provided in
| the
| PostgreSQL database scripts.
| 
| attributetype ( 1.3.6.1.4.1.13040.1.2.4.17
|         NAME 'turbaType'
|         DESC 'Distinguishes between a Contact object and a Group object'
|         EQUALITY caseIgnoreIA5Match
|         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{8} )
| 
| I haven't used the preferences based address books, but from a glance I
| guesstimate that one will need to add turbaMembers and turbaType to
| hordePerson.

AFAIK, it does.

<SNIP>

| Ideally, for LDAP sources, Turba would assume "Contact" if a "__type" field
| was
| defined but returned blank.    I presume that would involve creating a patch.

That sounds like the most practical solution.
| 
<SNIP>
| Is all of the schema for all the horde projects stored in the central
| horde.schema file?

As I mentioned before, it is generated dynamically by make_schema.php.
Somehow after reading your email, I'm begining to think that isn't a good 
idea:-)

Thanks again, Adam.

ed

 


-------------------------------------------------