Rebooting the network services working group

With last week’s release of the Futures 0.3 alpha, we’ve hit a major milestone in this year’s goals for networking services – in particular, we now have a working foundation for async/await in nightly Rust!

There’s so much work still to do in this space for Rust this year, including:

  • Working out the integration story between existing libraries and Futures 0.3. Likely this will start out as a Futures 0.1 <-> 0.3 shim, like the one @seanmonstar made for 0.2.

  • Mapping out, documenting and improving the network services ecosystem, including:

  • Writing a general guide to asynchronous programming in Rust.

  • Writing guidelines material for building networking-related crates (e.g., how to approach TLS)

  • Improving the debugging story around futures.

  • Boil all of the above down to various “getting started” guides.

And there’s surely a lot more!

We want to build a big-tent, cohesive “Networking Services Working Group” to tackle this work. Rather than approaching the work from the vantage point of any particular crate/project, we want to take a look holistically at the Rust networking experience, and find ways to help existing crates or gaps where new ones are needed.

If you are interested in networking services in Rust, even just as a user, we need your help! I’ve been personally reaching out to stakeholders, for example production Rust users, to collect gripes, but we need more gripes, and more hands to help fix the gripes.

To get involved, please:

  • Get on, and ping me with a “hello” on #wg-net.
  • Give your availability at this doodle poll for a text-based meeting on Discord this Friday.
  • Take a look at our repo, and start filing and commenting on issues – anything related to networking services in Rust is fair game!

This sounds good. Unfortunately, I do not currently have the availability to take part in synchronous discussions. Hopefully, there will be an opportunity to discuss things via github, otherwise I will not be able to participate.

Our kickoff meeting will be on 2017-07-27 at 8am Pacific. For this initial meeting, which looks to have ~30 attendees, we’ll talk over text in the Discord #WG-Net channel. For those of you who can’t do sync communication, we’ll in general push as much into the repo as we can.

I’ve started a document for meeting notes. There is also a roster at the bottom; if you want to participate in the WG, please add yourself!.

1 Like

I’ve added an agenda to the notes document – please have a look if you plan to attend, and “see” you all tomorrow!

The first meeting was a success! You can find the notes here.

We’ll be meeting on Discord again next week. Leave your constraints on the new Doodle poll if you’d like to join!

I’d love to start experimenting with the new async/await stuff and help find some bugs, but that’s pretty much out of the question until tokio is supported since I use that for everything.

Is there an ETA on when there’ll be a a futures-0.3-compatible tokio?

There is an open PR for the base compatibility layer currently (Future and Executor), once that’s merged I have some changes that add in support for Stream and Sink as well, along with some tokio specific compatibility to support tokio::executor::DefaultExecutor. Using those changes I managed to get a small tokio application running using futures(0.3): Those changes need some cleanup, but I hope to open a PR for them this week (although, the currently open PR may be blocked on cargo renaming support).

Once all that is merged I (or someone else if they get to it before me) will probably try and throw together a small example project of how to use futures(0.3) in the middle layers of a tokio project. Then we’ll probably be in a good spot to announce it on the futures-rs blog.

Probably the best way to keep a closer eye on it is to follow the WG-net issue for it, I’m going to try and keep it updated as we implement stuff.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.