Add rpc::future for callback support to client async calls about rpclib HOT 10 OPEN

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>();
        });
    
    });

from rpclib.

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

from rpclib.

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

from rpclib.

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

from rpclib.

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.

from rpclib.

What do you think about the proposed overload?

from rpclib.

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 ?

from rpclib.

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

from rpclib.

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

from rpclib.

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.

from rpclib.