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.
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
