>> 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). Again, the problem is, if no consistent behavior among the backends, how client would benefit? For example, some backend sort the results, but others don't, then how client know that, regarding the results sorted or not?
>> Here is what I suggest : get the cursor used, no matter what ... I'm afraid it's not easy to have a good, well discussed cursor or iterator interface design as you might think. Going this way would need much longer time. The most simple ==List<String> getIdentities()== would be good enough for the initial version, since it's only for internal use and we won't be so lucky to hit huge amounts of principals to store in the backend so soon ..., we can release often after the initial one, right? Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Sunday, July 05, 2015 1:43 AM To: [email protected] Subject: Re: How to implement getIdentities(int start, int limit) more effectively 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.
