Regarding the options to rpc/2-3, I’m starting to think that the default value of the limit option ought to be infinite rather than 1 (which is now the case). And the same should probably be true of the limit parameter for the HTTP API. (In fact, rpc/2-3 will “inherit” this default from the HTTP API.) It would mean that if a client makes a request
GET http://n1.org/ask?query=p(X)
the response will contain all solutions to ?-p(X) rather than just the first, and if a call such as
?- rpc('http://n1.org', p(X)).
is made, then, under the hood, all solutions to ?-p(X) will be retrieved (although the behaviour of rpc/2-3 will be the same as before).
This would mean that since the underlying queries are deterministic, such requests/calls will never leave entries in the node’s cache.
There will be fewer reasons to make use of the limit parameter/option. But, of course, our simple shell would still have to set limit to 1
GET http://n1.org/ask?query=p(X)&limit=1
and if the number of solutions to ?-p(X) is very large, or even infinite, is might be necessary to use
?- rpc('http://n1.org', p(X), [limit(N)]).
with a suitable N in order to avoid exceeding the timeout.
So given this change, rpc(URI,G) becomes equivalent to rpc(URI,G,[limit(infinite)]), which in turn is equivalent to rpc(URI,findall(G,G,L)).
Another potentially useful parameter/option might be once. For example, assuming ?-p(X) has three solutions, using once in combination with limit would only get us two of them:
?- rpc('http://n1.org', p(X), [
limit(2),
once(true)
]).
X = a ;
X = b.
Again, this will not add an entry to the node’s cache. Thus, if you know two solutions would be sufficient for your purpose, you are being “nice” to the node and its owner by using once in this way.
BTW, note that using the once parameter/option is not the same as running a goal once(Goal), which will only provide one solution:
?- rpc('http://n1.org', once(p(X)), [
limit(2)
]).
X = a.