its kinda kewl idea for ui progress indicators and alike. i'm not sure about "update me every N entries" part tho. say you have a candidate list you walk thru on the server side and presumably you wanna let the client know how many you walked and evaluated against the filter. now if you have result/s to return you can communicate that by attaching a control response with that data but if you got no results to return after you walked N entries/candidates how do you push updated progress data to the client? from ui progress indicator and user perspective it would become stale til the next result is sent and that can obviously happen when you have a very large candidate list and few or no actual results. did i misunderstood and you have something different in mind?
Howard Chu wrote:
Dunno if there's already anything like this, I haven't bothered to search yet.
I was considering adding the progress meter to ldapadd. Then it was suggested that it might be useful for slapcat/ldapsearch as well. For ldapsearch we would need a means to tell the client how large the result set is expected to be. Currently it's easy for back-bdb/hdb to provide this number, because they just walk through an IDL of candidates where the IDL size is already known. Of course the real result set size may be smaller due to actual filter evaluation.
This seems to call for a control that we could attach to a search request "give me an estimate of the result set size and update me every N entries". The response control would be attached to the first entry and every N entries after that, with an updated estimate of the total number of results. A control like this would be particularly useful for administrators using GUIs to browse a large directory, to give feedback about when they will receive the complete set of entries, and give an opportunity to decide to abandon the search or continue.
Comments?