> Yeah - but my point was that I want something that _does_ work with > existing apps that know nothing about the Netscape/Sun extensions like > nsRoles and memberURL - i.e. that could look up a "standard" > groupofuniquenames groups and see things in the uniquemember > attribute, without having to look at something else (i.e. nsRole). > That has always been the problem with using these extensions. So what > I am asking for _is_ different than the filtered roles, I think. :) This idea was considered when roles were developed and rejected at the time. Reason was that we didn't want to interfere with the existing behavior of static groups in any way. Another reason was that we didn't have high confidence in the whole static group concept : generating a single entry with a potentially vast number of attribute values can cause problems for clients. Microsoft attempted to solve this problem with the paged results control, I believe. Therefore roles attempted to steer applications in a different direction : the application reads the target entry and by examining attributes of that entry it can determine group membership (or entitlement to perform some operation, however the grouping semantics are to be interpreted within the application). This approach seemed to be more efficient from both a server and a client perspective. However, I don't think it would be too hard to leverage the roles code to make the kind of 'view group' feature that you want. Performance might not be great for large groups and the issue with clients reading huge group entries is still present.
