4 ms·
Batching and pipelining calls is a quite common design in RPC, especially databases. Mongodb for example has a very easy to use aggregate([op1, op2, ...]) funct
by Too 7y ago
Batching and pipelining calls is a quite common design in RPC, especially databases. Mongodb for example has a very easy to use aggregate([op1, op2, ...]) function which you use to build a pipeline of generic operations that all data flows through on the server side, eg input to op2 is the output of op1, and so on.
It doesn't allow any client logic between op1 and op2 if that's what you meant though?
- hinkley 7y ago> It doesn't allow any client logic between op1 and op2 if that's what you meant though? Yeah that seems to be the trick doesn’t it? Is the next step beyond pipelining A) provide a way to run limited code on the server end or B), reformulate the API so that these situations don’t occur as readily. Take a classic I/O pattern. Give me 5k of data from X, write all 5k out to Y. Except that’s not what actually happens. It tells you what it wrote and you have to do a conditional branch and arithmetic. I still recall feeling shocked and a little scandalized when I learned that these APIs worked like this. First, why didn’t you just do what I asked, and second, why am I the one held responsible for all of the bookkeeping when you are the one selectively following instructions? I think one of the features of completion ports was a slightly better, “go do this and don’t bother coming back until you have”.