Spec issue #53: Iterator, count and totalCount.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

1) I propose that we drop the 'count' and 'totalCount' attributes from 
ResultsIteratorType.
    Jeff Bohren and I agree that these are practically useless 
(especially on an iterator).

2) I also propose that a provider must return an error if a search 
result is incomplete.
   We should probably add a new value of ErrorCode like 
'insufficientResources'.

The original purpose of 'count' and 'totalCount' was to indicate that a 
search result was incomplete.  For instance, if a searchRequest selected 
more objects than a provider could return or cache for iteration, the 
provider needed some way to tell the requestor that the requestor wasn't 
going to get all of the objects that would have matched. (In such a 
case, 'totalCount' would be larger than 'count'.  If a result were 
complete, 'count' would equal 'totalCount'.)

I think it's cleaner (and Jeff points out that it is more explicit) to 
have the provider return an error if the searchResult is too large for 
it to handle. Jeff points out that a provider will not always know what 
the totalCount should be. (The provider only knows that it has exceeded 
a limit). Jeff also points out that, even if a totalCount were 
available, it might not be accurate. (Both of these are arguably more 
true of a directory service back-end than a DBMS back-end, but even a 
DBMS back-end would require a separate call to get just the count.)

Is there any objection?  Does anyone feel a deep sense of loss over 
'count' and 'totalCount'?