do you have any plan to update to tokio 0.2?

[nkbai]

Using RUST'S new syntax async & Await, the code is much cleaner.

ctx.read_holding_registers(address, count as u16)
            .map_err(move |err| {
                println!("Read input registers error {:?}", err);
                OutputRegister::end_read_output_registers(&runtime_for_err);
            })
            .and_then(move |values| {
                store_values_in_registers(values, registers.clone());
                OutputRegister::end_read_output_registers(&runtime);
                Ok(())
            })

it's hard to read code like this.

[locka99]

yes I intend to update to tokio 0.2 but not for 0.8 in case I end up breaking everything in order to fix it.

[nkbai]

I want to help you do this work, Can you elaborate on your idea or roadmap?

[locka99]

I don't have a roadmap beyond what is at the bottom of the CHANGELOG. In the first instance I would probably see what the tokio-compat layer does to ease migrating from 0.1 to 0.2. Failing that it would require a rewrite mostly of the session processing loops in the client and server.

I had some terrible issues with tokio when I moved to use it - passing context between futures was a huge pain as well as out of band events that terminate sessions. Timers were a problem too, especially because tokio-timer had some seriously broken granularity issues that were fixed eventually. I expect more of the same from any rewrite.

I haven't thought how to present an async API on the client. Under the surface the client actually is async but the sync API on top is probably easier for most developers to wrap their heads around. I imagine there would have to be two session interfaces, one of which resembles the current API and the other that is async.

[locka99]

I just released 0.8 so I can take a look at this just to see what effort is involved.

[nkbai]

https://github.com/seanmonstar/reqwestg this crate provides both async and sync api.

[nkbai]

@locka99 i'm upgrading opcua to tokio 0.2 and i'm woking on branch tokio-0.2 now. My first plan was to be able to compile successfully without relying on tokio-compact.

[nkbai]

I will also upgrade futures to version 0.3.

[locka99]

I have a tokio-0.2 branch at the moment with a number of changes but its not compiling yet. It uses tokio-compat just to get going.

[ctron]

I just wanted to check the status of this, as I would be interested in having support for Tokio 1.0.

I gave it a try, porting this over to the new Tokio 1.0 APIs, and while I was able to get it compile, it doesn't work anymore :grin: …

I am not sure if sharing the code makes sense, if you think so, I am happy to do it.

In general I think that it might make sense to change the APIs of this crate to use .await and async as well, as some constructs in my port had been a bit awkward, now that the async support is part of Rust. However, that was above my head, as I am not sure how I can help with this.

[locka99]

I haven't been involved in the actual port on the branch so I don't know the present status. It would be nice to have it in for obvious reasons.

[nkbai]

@cron can your branch sync with master branch? there are a lot of code format changes,

[locka99]

I'm working on a new Tokio branch against 1.8.x. It compiles, but I need to get it working for server / client. It was tedious to work through the code but the new async / await stuff is a lot cleaner.

[svanharmelen]

That is super good news!

[locka99]

I've upgraded master from 0.1 to 1.8.x. This is all under the covers. The client API is still synchronous & further work is probably necessary to make it nicer for people who want exposure to async . Tests & integration tests seem okay. I've tried server & client.

Future work might include providing an async client API (as an alternative to the sync API) but stuff like run_loop() in session,rs would all have to change.