Le 04/07/15 15:27, Zheng, Kai a écrit : > Thanks Emmanuel for the further discussion. > >>> My percezption is that the getIdentities() method should be made specific, >>> per backend. If a backend supports paged search and sort, fine, iyt can use >>> it. If it's not, then it should use a default implementation. In any cases, >>> the user should not be aware of what's going on behind the curtain. > Sounds good. One thing is we need a mechanism to let the client be able to > aware what's the capabilities a backend is of, paged search, sort and etc. If > the client isn't able to aware, how it make use of it.
I don't think it's a good idea. That would make it more complex for the clinet that it needs to be. I do think that the cursor implementation should be responsible for the sorting of data, same thing for the paged search (or to implement it if the backend does not). > >>> The best way to acheive this is to have the getIdentities() return a >>> Cursor, which can be handled by any client. > As I said before, the cursor or iterator (proposed by Stefan) looks good to > have. My only question is, could we delay this to next release? You may be > noted that it's not so easy for us in short time, we have quite a few > backends, and quite a few client calls to use the related API. We should be > able to get the most required things done and have the first release sooner > and better. Please note backend APIs are internal ones, no worrying for admin > and end users if we have. Ok, I see. Here is what I suggest : get the cursor used, no matter what, but don't implement specific cursors for backend that support paged search or sorting : instead define a DefaultCursor that do a full search, order the result, and return it. Every backend implementaion will use this DefaultCursor from now on, and after the release, we can improve the code by implementing smarter cursors.
