Context.current() accepts only Nodes, which are database-backed; QueryProcessor.context(), by contrast, can accept the ItemCache returned by a query which doesn't return a database reference.
As such -- it seems to me that what is needed is an extension to the query command protocol (as implemented by ClientListener.query()), since a QueryProcessor is available when query commands are being handled but not otherwise.
Helpful ideas. I thought about sth. similar, which is why I'll now add a new CONTEXT command with a value (using code \14) and optional type as arguments.
It might also be worthwhile to have an additional query command to the effect of "execute query with id1, bind result to query id2", as follows:
While I clearly see the advantages of that approach, I'm a little bit hesitant to introduce this feature too quickly, as I think this will introduce a number of open issues (some of the queries may be updating; it may be generally desirable to introduce the concept of transactions in order to perform multiple commands and queries with no other processes interfering; etc.).
My goal here, by the way, is to have feature-parity between the REST API and the server protocol -- the REST API allows the context item to be set when running an arbitrary, unmodified query; the server protocol, at present, does not.
Yes, that's absolutely sensible. Your feedback is welcome, Christian