Grouper Developers Forum

[Tom Barton <>]

I suggest expanding the size of the name column in the SubjectAttribute 
table to something substantially larger - maybe 255. Roomier than 32 for 
OID or URI style attribute names.

Not for discussion in connection with v0.1, but perhaps at a later time 
we might ponder whether (1) Subject API client programs need to have 
configuration elements that tell them how to do whatever translational 
searches necessary for that client (ie, functional requirement #5), or 
(2) the Subject API configuration file should have optional elements 
that declare any distinguished (possibly registered?) search strategies 
that a subject adapter implements, and those declarations are exposed 
through a method in the Source interface.

Tom

Minh N. Nguyen wrote:
> A second draft of the Subject API 0.1 spec is available at 
> http://www.stanford.edu/dept/itss/infrastructure/signet/project/doc/subject-api-spec-0.1-draft-02.html. 
> This second draft reflects my attempt to reduce the spec to the core 
> functionalities that are needed by Grouper and Signet.
>
> Also, in several working group calls, we've debated over how to uniquely 
> identify a subject, i.e. source+id, type+id, and whether this 
> functionality should be handled within the Subject API or by the 
> applications which uses the API.  Letting applications arbitrarily 
> determine uniqueness may lead to interoperability issues.  
> Programmatically, we need to adopt a consistent way to evaluate whether 
> two subjects are equal or not.  I'd like to propose that we add to the 
> API an abstract subject class which overrides the equals() method.  This 
> method will return true if two subject objects have the same source, 
> type, and id.
>
>
> --Minh