[turba] __type attribute for LDAP

[Adam Tauno Williams]

>>Ok.  I'm assuming that .16 and .17 are the next available object OID
>>values by looking at the distributed horde.schema file.
>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?  

Yes.  The numbers have no meaning and can be nested as much a one wants.  If
starting at 201 avoids problems then that is what should be done.

>I would assume that we should not be changing the OID value.  Do you agree?

Agree.  The OID number and attribute/objectclass should be fixed.  "Wandering"
schema makes distributed directories and things like slapi almost impossible.  

More and more organizations are starting to use referrals to peer with other
ogranizations as a really nice way to share information.  So it may never have
caused a problem in the past,  but possibly will in the future  (assuming that
two organizations or divisions that use Turba decide to start referring to one
another).
 
>>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.

This change would occur in horde/turba/lib/Driver/ldap.php?  I'm willing to take
a crack at it.

><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:-)

Nope, it isn't.