plietar
commented
5 days ago A quick search across GitHub for this suggests it is just hipercow and daedalus using it: https://github.com/search?q=offload_path+language%3Ar&type=code
~Haven't implemented the hipercow side of it. Will do that before merging this.~ https://github.com/mrc-ide/hipercow/pull/145
rrq used to treat the offload path as a global property, shared by all clients. When using rrq across multiple machines (eg. on the hipercow cluster), the offload directory might be mounted at different paths on each machine. The different machines might even be on different operating systems, in which case absolute paths from one OS don't even make any sense on the other.
This makes the offload path a property of the controller instead, and each controller can use a different path. As an added bonus, a controller can be created without any offload path, in which case it can still access the queue, but any operation that requires access to the offload directory will fail.
In hipercow, the offload directory will be configure relative to the hipercow root. hipercow already is able to map paths differently based on whether it is executing on the user's machine or on a cluster node.
The only user of the offload directory other than hipercow is daedalus.api, which will need a pretty minor migration. The existing configuration API is preserved for now to make this easier, but shows a deprecation warning and might be removed in the future.