| Re: [higgins-dev] Proposed change to IdAS |
|
Even in such a case (where the DS represents a conn which can be queried on a per-attribute basis), that DS could choose to ignore the list, or it could do something like pre-fetch attributes in a low-priority thread if that seems like a perfomance-add. >>> Michael McIntosh <mikemci@xxxxxxxxxx> 11/30/06 12:49 PM >>> higgins-dev-bounces@xxxxxxxxxxx wrote on 11/29/2006 08:44:30 PM: > Shouldn't cause any problems for anyone. Regardless of the > idiosyncracy of JNDI and operational attributes, it was discussed > long ago that we'd want the ability to limit what attributes come > back for a given DigitalSubject, especially given that some > DigitalSubject may be composed of thousands of attributes. Why > waste the time and memory space if we're only interested in a very > small and known number of them as is the case with the STS. I think your reasoning makes sense if you assume that DigitalSubjects are created in a way that forces them to hold/cache all of their attributes. An alternative would be to have the DigitalSubject own a connection thru the CP and fetch attributes on each get. > > Tom > > >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 11/29/2006 4:59 PM >>> > While integrating code for the demo, we found that we needed to > allow an IdAS consumer to specify a list of attributes to fetch when > calling IContext.getDigitalSubject. > > As it turns out, the JNDI provider requires certain types of > attributes (in LDAP called "operational attributes") to be fetched > if asked for by name. There's no way (with JNDI) to fetch "all > operational attributes". > > So locally, I've added IContext.getSubject(String cuid, > Iterable<URI> attrSelectionList) where attrSelectionList is a list > of attribute types that the consumer expects to read from the > resulting IDigitalSubject. I just wanted to see if this causes any > problems before I committed it. > > Jim > _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |