RE: Batch Lookup (was "Re: ReadOnlyProfile")

["John, Anil" <Anil.John@jhuapl.edu>]

Gary,

>Search gives you by default the equivalent of a batch lookup.

So it does, and a constrained-search profile would meet the functionality we are looking for (based on your description below).  Our perspective was shaped in a lot of ways by the reluctance of product implementations to implement anything beyond the basic operations on a SPML provider.  Search is an optional capability (and so is batch, but thought that it would be easier to make a case for it).

I would be interested to get the perspective of folks who are product implementors to see what would be "easier" to implement for them going forward. At the end of the road, we are looking for something that will exist in real-life within products and not just as shelf-ware.

Regards,

- Anil

________________________________________
From: Gary Cole [gary.cole@oracle.com]
Sent: Tuesday, March 29, 2011 9:20 AM
To: John, Anil
Cc: Smith, Thomas C.; OASIS PSTC
Subject: Batch Lookup (was "Re: ReadOnlyProfile")

Anil,

On Mar 29, 2011, at 7:43 AM, John, Anil wrote:
> We also need to re-read the specs to see if there is overlap between
> lookup() and search on what we need to accomplish.

Remind me again please what you need to accomplish.  I may be able to
help.

For instance, I may be able to clarify something about your
requirements for "SPML Operations on an Attribute Service".  You
originally thought that you needed "batch pull" capabilities because
SAML Attribute Query could not answer the following questions:
   * "Give me the unique id's of all users with Attribute X"
   * "For all users (whose unique id's I just got), give me listing of
attributes for each (in one shot)"

SPML's Search Capability (section 3.6.7.1 of the main spec) gives you
all of that in one shot.  You can request one search() and in that
request use the 'returnData' attribute to specify how much information
you want back for each matching object:  nothing, identifier-only,
data (which would include all schema-defined attributes) or
everything, which would add capability-specific data to schema-defined
data.  Another parameter allows you to specify which capabilities
interest you.  In your case, you would specify "returnData='data'", so
that you would get all of the attributes.  Or you could take the
default, which is 'everything'.  Unless you have capability-specific
data, 'everything' is equivalent to 'data'.  A client can also specify
a maximum limit on the number of matching objects to return.

The Provider may send all of the matching objects in a single
SearchResult, or the provider may break the results into chunks that
the requestor can iterate.  Logically, it's still part of a single
search result, although a series of iterate() requests may be
necessary to return all matching objects.

So, please help me to understand what a batch operation would add to
this?  Search gives you by default the equivalent of a batch lookup.

Gary