Fix (really unlikely) 'count' bug #5
Conversation
The reset should take place _after_ the remote call.
Now, local callbacks are called via apply. This is necessary
when e.g. wrapping around node modules.
Example:
var server = rpc({
foo: function(arg1, arg2, arg3, cb) {
// do something with all args
cb(null, arg1+arg2+arg3);
}
});
var client = rpc();
client.pipe(fserver).pipe(client);
client.rpc('foo', [1, 2, 3], function(err, res) {
// res will be 6
});
Before, the foo function only received 2 arguments: a list with all
arguments and the callback. This was not useful when wrapping around node modules, e.g. fs.
No responses were emitted.
|
hi, I merged the first two commits, but not riga@3699289 because it broke the tests - I used to have it that way, |
|
Thanks for merging! I see your point with the |
|
oh, hmm - that example is out of date... I should update that. I can't merge the rest of this though, because it's a breaking change, and this api is being used in multilevel -- multilevel is the most important use case for rpc-stream maybe if you add another method that is a short cut for that kind of thing? |
|
Sorry for making 2 commits to solve this. riga@ FYI: we plan to use rpc-stream and rpyc-stream for distributed handling & processing of physics analyses at our institute. edit: By the way, what confused me was the |
|
cool! real science! can you tell me more? |
|
Software installation/dependencies and software, resource and data availability are major questions in physics. |
|
just stumbled upon that args issue. I'd need to wrap my modules by hand to be able to call the remotely, now? |
The reset should take place after the remote call to keep the counters consistent.
I'm porting your rpc-stream idea over to python and stumbled over this 'bug' (but I never had to reset the counter....so no beer for me ;) ).
edit: The Python port works, see https://github.com/riga/rpyc-stream