Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Proposed change to IdAS

I think I’d do the easy thing for now and just add the method. [We can work on adding a method extension mechanism later. We should take advantage of the fact that we can still for a time make code-breaking API changes.]

BTW, speaking of IdAS methods to add… I’ve been wondering if we need a “merge one DS (well, all of it’s attributes other than its CUID attribute) into another DS and delete the first DS” method. It’s just a convenience method. And it would be atomic as all IdAS methods are.

-Paul

From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Thursday, November 30, 2006 12:07 PM
To: higgins-dev@xxxxxxxxxxx
Subject: Re: [higgins-dev] Proposed change to IdAS

 

I guess the other consideration would be which methods to add this kind of thing to, and also whether this kind of thing should be part of a larger "extension" type.  By the latter, envision some kind of extensible object that could be passed to various methods such that CPs could support (or not) various method extensions.  The hopes would be to a) prevent the method signatures from changing over and over as we add new capabilities, and b) allow anyone to define their own new capabilities.

 

This is the kind of thing that will take a bit of thought, so I'd like to know whether people think it's worth it before I plow ahead.

 

Jim

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 11/29/06 6:44 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.

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

Back to the top