On Tue, 2006-03-14 at 10:52 -0500, Enrique Rodriguez wrote: > John E. Conlon wrote: > > On Thu, 2005-12-29 at 11:31, Enrique Rodriguez wrote: > > > >>Great. Again, I don't know your use case. BTW, the config admin > >>service isn't totally done: not all of the store ops work. I'd love > >>some help here; their impl should be straightforward, I just have only > >>done the ones I need. > >> > > > > How can I help? > > I figure you can check out and review the OSGi work on Directory 1.1 or > pitch in on the use of CM for what is currently in the XML config. Or > help in moving CM, Prefs, and UA over to Felix. They'll need an M2 > update, basic dep updates (refactoring, renaming packages), and > eventually updates to be R4-compliant. Also, not all of the > directory-backed CM store was implemented; I only did what I needed to > make directory work. Patches here would be great. > > > How will you provide for attributes that have multiple values, like > > objectClasses? >
> While they are returned by JNDI, I believe CM will ignore them. If this > is outside the scope of CM then there isn't much we can do. Multiple > values in config is typically on one line which gets tokenized. This is > how I would do a multi-value, for example Kerberos encryption types; put > them in the DIT as one long string. Or now, that I think about it, they > could be multi-valued in the DIT and converted to one-line strings by > the CM and parsed by the receiving service? WDYT? After reviewing the spec I think that the CM is limited (broken?) in this regard. Maybe I am wrong and they did it for some good reason but it sure makes it difficult to map real dit multi-objectclass entries like an inetOrgPerson to CM. (There is so much in the spec references LDAP that I wonder why this is speced like this.) This limitation also seems to cascade into the Meta Type service. Too bad with the LDAP schema and JNDI I think we could have easily provided dynamic ObjectClass Definitions for all entries IF the CM and MetaType were speced different. (If wishes were fishes.) Maybe a question into the [email protected] mailing list is in order? Back to your quesion - If they are multi-valued in the DIT and converted to one-line strings by CM I think we could generate something useful in CM and keep the DIT more DIT like. Perhaps we could even generate something in CM from standard entries that have multiple attributes with the same name? I'll have to look, but I wonder if the interaction between the CM and the MetaType specs show that one way is better than the other? John
