dbus-codegen: Option to generate async code

[zeenix]

dbus-codgen should be able to generate async code that makes use of dbus-tokio crate. I plan to work on this (or get a GSoC student to) as requirement for https://gitlab.freedesktop.org/geoclue/geoclue/issues/103 but adding it here already in case someone wants to beat me to it. :)

[diwic]

So I pushed a commit earlier today for dbus-futures, so begin by checking git master :-)

Although that is the initial client-side work only, not server part.

What I'm thinking now is deprecate dbus-tokio when futures 0.3 / async / await / etc becomes stable, and have dbus-futures support Tokio as an event loop backend.
Do you need an intermediate solution until that stuff is stable?

[zeenix]

So I pushed a commit earlier today for dbus-futures, so begin by checking git master :-)

Hehe, sure. :) Thanks.

Although that is the initial client-side work only, not server part.

Right and geoclue needs the server side.

What I'm thinking now is deprecate dbus-tokio when futures 0.3 / async / await / etc becomes stable, and have dbus-futures support Tokio as an event loop backend.

Sounds good.

Do you need an intermediate solution until that stuff is stable?

I'm neither sure about my own timeline on this, nor that of future 0.3/async/await becoming stable. :( What I do know is that I plan to start the basic implementation (dummy one at least) before summer at latest, so I know how the new code architecture would be like and hence can guide the student(s) during the GSoC.

[diwic]

I'm neither sure about my own timeline on this, nor that of future 0.3/async/await becoming stable. :( What I do know is that I plan to start the basic implementation (dummy one at least) before summer at latest, so I know how the new code architecture would be like and hence can guide the student(s) during the GSoC.

I think it kind of depends on how future proof you want your code to be as well.

It seems like async/await/futures 0.3 is becoming stable during 2019, although you don't know for sure until it's there. But if it's semi-stable, then you can work with the nightly compiler until it's stable.
Whereas Tokio + Futures 0.1 just might be deprecated soon after Futures 0.3 is stable. And then it might make less sense to develop new code for Futures 0.1. Anyhow I've put my eggs in the Futures 0.3 basket for now.

[zeenix]

I think it kind of depends on how future proof you want your code to be as well.

Right. I wouldn't mind changing things in my experimental branch, just not merge it until it depends on more stable API. However, I could also go with sync dbus at first and convert to async when the time is right.

[jmagnuson]

In case anyone is interested, I hacked up a futures 0.1 codegen fork over the weekend:
jmagnuson@58e5048

The type signature returns Box<Future> using dbus::ConnPath<'a, Qutex<AConnection>>, but should be pretty easy to modify for what ever. Definitely open to a better way of doing it, but the lock was necessary to be able to share the connection with multiple object structs.

In action here:
https://github.com/jmagnuson/connman-rs/blob/d72ff610cc727d01f1e88420f25d4886fb239d20/src/api/gen/manager.rs#L75

[diwic]

@jmagnuson Very interesting!

It only covers client side code though, and I think @zeenix was more interested in the server side of it, but still.

Definitely open to a better way of doing it, but the lock was necessary to be able to share the connection with multiple object structs.

Edit: I wrote an answer to this but it was wrong. Anything that Derefs into an AConnection should work, like e g Rc<AConnection>. Right? You don't need a mutable reference to make a method call.

[jmagnuson]

My bad, missed the part about it being server-specific.

Anything that Derefs into an AConnection should work, like e g Rc.

Yep, you're right. I think I had Send-ability on my mind when I used Qutex. But in reality both dbus-tokio and my application use current_thread::Runtime, so Qutex isn't necessary.

[diwic]

So, to what degree are we interested in merging @jmagnuson s branch? There are indeed some non-trivial issues to resolve first, and my time is limited w r t working on that myself, at least currently.

My long term plan is to write something for Futures 0.3, including a new "tree" replacement, so I'd rather spend my time on that.

I think I had Send-ability on my mind when I used Qutex.

Well, Connection isn't Send in the first place (see #137 ) so I'm not sure how a Qutex would help...

[zeenix]

So, to what degree are we interested in merging @jmagnuson s branch?

At least I'm not in a huge hurry atm. As agreed before, I'll first use the synch code and convert it to async later once we've the support for that.