There has been some discussion lately about how to best deal with large payloads. In particular, we've been trying to trying to transfer ~hundreds of kB of data from an SQL select for storage elsewhere, though in the past we've also transferred long arrays of data from, say, the lockin or others. I think that the dripline standard itself should address this, a few options come to mind:
1) Set some cap on message payload size and define a means by which larger payloads can be split, sent as a set of multiple replies, and combined at the end. This is non-trivial effort but scales and should be a "forever" solution.
2) Dictate that dripline communication is for instructions and replies, but not larger data transfers. Qualitatively state that "large" transfers are not supported and/or discouraged, and then continue to move forward roughly as we are now. This is less precise but seems to be what is happening naturally.
3) some other idea?
There has been some discussion lately about how to best deal with large payloads. In particular, we've been trying to trying to transfer ~hundreds of kB of data from an SQL select for storage elsewhere, though in the past we've also transferred long arrays of data from, say, the lockin or others. I think that the dripline standard itself should address this, a few options come to mind:
1) Set some cap on message payload size and define a means by which larger payloads can be split, sent as a set of multiple replies, and combined at the end. This is non-trivial effort but scales and should be a "forever" solution. 2) Dictate that dripline communication is for instructions and replies, but not larger data transfers. Qualitatively state that "large" transfers are not supported and/or discouraged, and then continue to move forward roughly as we are now. This is less precise but seems to be what is happening naturally. 3) some other idea?