"The problem with that approach, other than exposing an LDAP specific object to a model object, is it still doesn’t satisfy the requirement of pulling the additional attributes."
I certainly understand the desire to support different back-ends, and so it's probably also not wise to "pollute" the various Mgr classes with Entry objects (via the callbacks). I didn't realize that you weren't pulling all the attributes, so both the getEntry() method and the callbacks on create, update and delete aren't really useful. At one point we'd also talked about giving Fortress a SCIM interface. I think we should talk through this a bit more but my initial thought is that the Fortress related Entry objects (in LDAP-speak) could be exposed as SCIM extensions, but the implementor might want to implement their own SCIM extensions, so the back-end would have to have a mechanism to allow CRUD on those objects. And so we're right back to the original topic of custom object classes and attributes. Steve "And so I pretend not to hear her. And go out to get an envelope because I'm going to have a hell of a good time in the process of buying one envelope. I meet a lot of people. And, see some great looking babes. And a fire engine goes by. And I give them the thumbs up. And, and ask a woman what kind of dog that is. And, and I don't know. The moral of the story is, is we're here on Earth to fart around. And, of course, the computers will do us out of that. And, what the computer people don't realize, or they don't care, is we're dancing animals. You know, we love to move around. And, we're not supposed to dance at all anymore." - Kurt Vonnegut
