[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [higgins-dev] Proposed change to IdAS
|
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