> So with the refs in place I could use the full remote logic to run pilog
> queries on the remotes.
> Now a search is made for all articles containing the word "picolisp" for
> instance. I then need to be able to get an arbitrary slice back of the total
> which needs to be sorted by time. I have a hard time understanding how this
> can be achieved in any sensible way except through one the following:
> Central Command:
I think both solutions are feasible. This is because you are in the
lucky situation that you can separate the articles on the remote machine
according to their age. In a general case (e.g. if the data are not
"archived" like here, but are subject to permanent change).
However: I think there is a solution that is simpler, as well as more
general (not assuming anything about the locations of the articles).
I did this in another project, where I collected items from remote
machines sorted by attributes (not date, but counts and sizes).
The first thing is that you define the index to be an +Aux, combining
the search key with the date. So if you search for a key like "picolisp"
on a single remote machine, you get all hits sorted by date. No extra
Then, each remote machine has a function (e.g. 'sendRefDatArticles')
defined, which simply iterates the index tree (with 'collect', or better
a pilog query) and sends each found object with 'pr' to the current
output channel. When it sent all hits, it terminates.
Then on the central server you open connections with *Ext enabled to
each remote client. This can be done with +Agent objects taking care of
the details (maintaining the connections, communicating via 'ext' etc.).
The actual query then sends out a remote command like
(start> Agent 'sendRefDatArticles "picolisp" (someDate))
Now all remote database start sending their results, ordered by date.
They are actually busy only until the TCP queue fills up, or until the
connection is closed. If the queue is filled up, they will block so that
it is advisable that they are all fork'ed children.
The central server then reads a single object from each connection into
a list. Now, to return the results one by one to the actual caller (e.g.
the GUI), it always picks the object with the highest date from that
list, and reads the next item into that place in the list. The list is
effectively a single-object look-ahead on each connection. When one of
the connections returns NIL, it means the list of hits on that machine
is exhausted, the remote child process terminated, and the connection
can be closed.
So the GUI calls a function (or, more probably) a proper pilog predicate
which returns always the next available object with the highest date.
With that, you can fetch 1, 25, or thousands of objects in order.