Skip to Content.
Sympa Menu

grouper-dev - Re: 2nd Draft of Subject API Spec

Subject: Grouper Developers Forum

List archive

Re: 2nd Draft of Subject API Spec

Chronological Thread 
  • From: Tom Barton <>
  • To: "Minh N. Nguyen" <>
  • Cc: ,
  • Subject: Re: 2nd Draft of Subject API Spec
  • Date: Thu, 09 Jun 2005 13:14:27 -0500

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.


Minh N. Nguyen wrote:
A second draft of the Subject API 0.1 spec is available at 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.


Archive powered by MHonArc 2.6.16.

Top of Page