Add rpc::future for callback support to client async calls

[sztomi]

No description provided.

[ahoarau]

Would you consider having rpclib::future instead of std::future ? I read that .then() operator is not gonna be in c++ for a while.

[ahoarau]

The folly library from facebook implements them, but I guess this dependency is way too big.

• https://code.facebook.com/posts/1661982097368498/futures-for-c-11-at-facebook/
• https://github.com/facebook/folly/tree/master/folly/futures
  And also this guy that implemented then() in c++14 only :
• https://github.com/jaredhoberock/future

[sztomi]

And sorry, it seems I never replied to this: yes, I'd consider it, absolutely.

[sztomi]

So my thinking is: providing rpc::future is one way to solve this, but it would also be possible to do it without that. For example, async_call could have an overloaded signature like:

std::future<RPCLIB_MSGPACK::object_handl> async_call(invocation i, callback c);

And used like:

client.async_call({"hello, 2, 3}, [](something) { ... });

Obviously, rpc::future would look smoother but that's paid for by additional complexity in the library. That is not say I'm against it, but I do want to see what options are there.

BTW I'm doing some breaking changes for 3.0, so pretty much anything goes for now in terms of interface breakage.

[ahoarau]

Excellent. I really look forward for this feature.

For now I'm using this hack in Qt :

    connect(ui->actionCalibrate,&QAction::triggered,this,[=](){

        auto f = client->async_call("calibrate");

        QFuture<void> future = QtConcurrent::run([this,&f](){
            bool done = f.get().as<bool>();
        });
    
    });

[sztomi]

What do you think about the proposed overload?

[ahoarau]

That would work, but I think that would be clearer to have :

auto f = client->async_call("add",2,3);
auto f = client->async_call("add",2,3).then( [](){} );

Rather than :

auto f = client->async_call("add",2,3);
auto f = client->async_call( {"add",2,3} , [](){} ); // is that you'd construct the invoker ?

[sztomi]

Yeah, that's pretty much my proposal.

I agree that .then is probably better, but it's also a bit more complicated to implement. I wonder if there is a good C++11 implementation of it which is a lot like std::future but with then

[ahoarau]

I think you can take from https://github.com/jaredhoberock/future, it seems promising 👍

[sztomi]

If I understand correctly, that is a third option: then as a free function.

But I also found that boost::future can provide a then function. So I'll probably use that.