I am really of mixed mind on this issue.
Just yesterday I completed my initial implementation of client side sorting in user interface tree objects which are driven by JNDI w/ OpenLDAP as the reference DS.
As a basic philosophy during this implementation I've tried to shy away from vendor provided extensions and conveniences, favoring 'build' versus 'buy' on these issues and sticking to the basic bind and search directory context requests.
When it came time to sort for the UI there was definately a temptation to use those good LDAPv3 and JDK 1.5 SortControl extensions to do the work for me. On the other hand (since I couldn't 8{) ) it turned out to be a very easy matter to sort the result sets on the client (aren't collections nice!). I have complete control over the sort constraints and I know I'm not burdening the LDAP server for doing this for [n] clients and [n] objects. As well I'm maintaining my philosophy about staying clear from those juicy and alluring vendor specific DS provided extensions. For the time being, I guess, I'm actually glad it wasn't there (as twisted as that sounds).
The flip side is that other vendors *are* providing these extensions and this, in turn, might affect the decision for some users to use something other than OpenLDAP. This is bad for us all! An area that is similar to this, from my perspective, is transaction/rollback support. Similar tradeoffs WRT the application developer, IMHO.
If I had a single request for OpenLDAP it would be to dramatically increase the performance of deletes and implement server side sort only if needed to compete with the other major DS vendors.
Best regards,
--
Tim