Glad to explain. My argument is a bit simplistic; as a matter of API design, it's preferable to have a single return mechanism for multiple returns.
I realize there were likely technical reasons for the decision, but it makes for a less uniform API and in particular becomes a greater concern if we elect to add new method signatures returning multiple items. I'm not clear on what you mean by the "non-destructive" nature of contents() requiring a remote iterator to be useful. At my company, we actually wrapped the method to so that we'd ultimately get a collection (by exhausting the iterator). Also, contents() presumably sets 'read' locks if a transaction is used, creating reservations for future takes, so doesn't the level of 'destructiveness' depend on usage? Now, that's not to say I'm deadset against the remote iterator approach. Remote iterators might save some memory/cpu overhead for truly massive requests, particularly if the user does not necessarily want every entry (though were that the case, maxEntries should have been used). On the other hand, returning a collection would spare network costs of sustained remote iterator interactions and the mild timing uncertainties its usage entails. And the remote iterator is more complex by its nature. In any case, I think it would be best to standardize on one or the other. Perhaps as someone involved with Javaspace05, you can illuminate some of the decision making surrounding the current usage of both? jamesG -----Original Message----- From: "Dan Creswell" <dan.cresw...@gmail.com> Sent: Monday, December 20, 2010 4:19am To: river-dev@incubator.apache.org Subject: Re: Space/outrigger suggestions James G, Can you explain some more about this statement please? "3) Collections or remote iterators, not both. "contents" returns a remote iterator named "MatchSet", while "take (with collection)" returns a collection. I can understand the argument behind both use cases, but not necessarily the argument for using both simultaneously. " This has been heavily discussed in the past and contents(), by virtue of it's non-destructive nature (unlike take) needs something akin to a remote iterator to be practical/useful. Multiple takes allow you to eventually exhaust a space's contents, multiple reads won't do similarly. So, given I'm scarred with the previous efforts of space implementation including JavaSpace05 I fear my past is colouring my thinking so I'd like to understand more. Cheers, Dan.
