[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: DIT tree question



Rob Tanner wrote:

> That's a significant qualifier to your previous post.  I guess one
> question would be whose responsible for maintaining the data?  If it's
> the customer, then you are probably much wiser to back off.  Your
> "added value" could end up being a minus rather than a plus.  Another
> question: if each of the ou's you referred to in your original post is
> a separate customer, is the data that comprises customer A's specific
> attributes confidential, or can customer B see it without a problem,
> and do you know that answer to this question in some documentable form
> should one or the other customer take you to court over the matter?

The data will initially be managed only by our own webbased community
software. External organizations use our sollution to provide their members
an online community. One of the benefits of this is that the customer can
maintain their own personal data, thus reducing this cost for the customer.
Providing the data directly to the customer (let them access the LDAP
server directly) is secondary, and will happen later.

I think we agree that the LDAP data model isn't suited for sharing
attributes between entries, as is really what we're interested in doing. It
just seems to be a waste to multiply data just because of a limited data
model.

I don't think any customer will go to cort over us, since we will "own" the
data ourselves.

What about auxilary objects? If it was possible to just multiple auxilary
objects to e.g. an inetOrgPerson, this would probably be good enough.

An example would be that an organization says that "we need to attach our
membership number for this person to the entry". If I could use an auxilary
objectclass specifically made for this customer, and with an attribute
"label=organization XYZ" then this would probably be the best option.


--
- Torgeir