Hi Henrik, > So with the refs in place I could use the full remote logic to run pilog > queries on the remotes.
OK > 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: > ... > Cascading: > ... 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 sorting required. 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. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe