├── CODE_OF_CONDUCT.md ├── LICENSE ├── README.md ├── meetings ├── 2018-07-27.md ├── 2018-08-03.md ├── 2018-08-31-net-wg-leads.md ├── 2018-09-06-net-web-wg.md ├── 2019-02-14.md ├── 2019-02-21.md ├── 2019-02-28.md ├── 2019-03-07.md ├── 2019-03-14.md ├── 2019-03-28.md ├── 2019-04-04.md ├── 2019-04-11.md ├── 2019-04-18.md ├── 2019-04-25.md ├── 2019-05-09.md ├── 2019-05-16.md ├── 2019-05-23.md ├── 2019-05-30.md ├── 2019-06-13.md ├── 2019-06-20.md ├── 2019-06-27.md ├── 2019-07-04.md ├── 2019-07-11.md └── 2019-07-18.md └── rfcs ├── 0000-template.md └── 0001-sprint-1.md /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # The Rust Code of Conduct 2 | 3 | A version of this document [can be found online](https://www.rust-lang.org/conduct.html). 4 | 5 | ## Conduct 6 | 7 | **Contact**: [rust-mods@rust-lang.org](mailto:rust-mods@rust-lang.org) 8 | 9 | * We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic. 10 | * On IRC, please avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all. 11 | * Please be kind and courteous. There's no need to be mean or rude. 12 | * Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. 13 | * Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. 14 | * We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behaviour. We interpret the term "harassment" as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don't tolerate behavior that excludes people in socially marginalized groups. 15 | * Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the [Rust moderation team][mod_team] immediately. Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back. 16 | * Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome. 17 | 18 | ## Moderation 19 | 20 | 21 | These are the policies for upholding our community's standards of conduct. If you feel that a thread needs moderation, please contact the [Rust moderation team][mod_team]. 22 | 23 | 1. Remarks that violate the Rust standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.) 24 | 2. Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed. 25 | 3. Moderators will first respond to such remarks with a warning. 26 | 4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of the communication channel to cool off. 27 | 5. If the user comes back and continues to make trouble, they will be banned, i.e., indefinitely excluded. 28 | 6. Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology. 29 | 7. If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, **in private**. Complaints about bans in-channel are not allowed. 30 | 8. Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others. 31 | 32 | In the Rust community we strive to go the extra step to look out for each other. Don't just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they're off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely. 33 | 34 | And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow Rustaceans comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust. 35 | 36 | The enforcement policies listed above apply to all official Rust venues; including official IRC channels (#rust, #rust-internals, #rust-tools, #rust-libs, #rustc, #rust-beginners, #rust-docs, #rust-community, #rust-lang, and #cargo); GitHub repositories under rust-lang, rust-lang-nursery, and rust-lang-deprecated; and all forums under rust-lang.org (users.rust-lang.org, internals.rust-lang.org). For other projects adopting the Rust Code of Conduct, please contact the maintainers of those projects for enforcement. If you wish to use this code of conduct for your own project, consider explicitly mentioning your moderation policy or making a copy with your own moderation policy so as to avoid confusion. 37 | 38 | *Adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling) as well as the [Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/).* 39 | 40 | [mod_team]: https://www.rust-lang.org/team.html#Moderation-team 41 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2018-2019 rustasync 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Rust 2019 Async Ecosystem Working Group 2 | 3 | ## ⚠️ Deprecation notice ⚠️ 4 | 5 | The [Rustasync working group has 6 | sunset](https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html#restructuring-async-io-in-the-rust-org) 7 | Runtime is no longer active. It was active from mid-2018 until fall 2019. It was 8 | disbanded in anticipation of `async/await` stabilizing in Rust 1.39, as 9 | ecosystem adoption had reached a point that a dedicated working group was no 10 | longer needed to help shepherd it. 11 | 12 | ## About 13 | 14 | This repo is for coordinating the Rust Async Ecosystem Working Group. 15 | 16 | - [Announcement of the 2019 working group reorganization][async-working-groups] 17 | - [Background on the original WG-net 2018 working groups is here.][wg-net-working-groups] 18 | - [Come chat with us on #wg-async-ecosystem! #wg-async-foundation to chat with the Async Foundations WG!][discord] 19 | 20 | The [issue tracker] on this repo is a primary point of coordination. If you have an async-related topic you'd like to raise, please feel free to open an issue! 21 | 22 | [async-working-groups]: https://blog.yoshuawuyts.com/async-ecosystem-wg/ 23 | [wg-net-working-groups]: https://internals.rust-lang.org/t/announcing-the-2018-domain-working-groups/6737 24 | [discord]: https://discord.gg/rust-lang 25 | [issue tracker]: https://github.com/rustasync/team/issues 26 | 27 | # Goals and structure 28 | 29 | - **Leads**: @aturon and @yoshuawuyts 30 | - [Vision document and roster](https://rustasync.github.io/team/web-foundations) 31 | 32 | The WG is focused on progressing the ecosystem around the async foundations in 2019. If you want to get involved in these efforts, hop on [Discord][discord] and say hello, or take a look at the [issue tracker]. Our goal is to improve the async library ecosystem in Rust by: 33 | 34 | - **Bolstering web components**, i.e. assessing the state of foundational crates for web programming (like `http` and `url`), and working to improve it by writing documentation and examples, making API improvements, standardizing interfaces, and in some cases writing whole new crates. 35 | - **Building _Tide_**, which is a combination of a simple, modular web framework built on the above components, and extensive documentation on what the components are, how to use them directly, and how they integrate into a framework. The name "Tide" refers to "a rising tide lifts all boats", conveying the intent that this work is aimed to improve sharing, compatibility, and improvements across *all* web development and frameworks in Rust. 36 | - **Experimenting** with projects such as the [Juliex][juliex] executor, the [Romio][romio] reactor, and the [Runtime][runtime] crate 37 | - **The [Asynchronous Programming in Rust book](https://github.com/rust-lang/async-book)** should have a complete draft, covering async/await, core futures concepts, Tokio, and enough of the ecosystem to give good examples and guidance. It should also explicitly talk about the stabilization situation, including how to bridge between stable 0.1 and unstable 0.3 worlds. 38 | 39 | [juliex]: https://github.com/withoutboats/juliex 40 | [romio]: https://github.com/withoutboats/romio 41 | [runtime]: https://github.com/rustasync/runtime 42 | -------------------------------------------------------------------------------- /meetings/2018-07-27.md: -------------------------------------------------------------------------------- 1 | # Kickoff meeting 2 | 3 | ## Agenda 4 | 5 | This kickoff meeting will mostly be about orientation: reaching a common understanding of what the WG is about, and what is feasible to accomplish this year. There are going to be a lot of us attending, so @aturon is going to rule the floor with an iron fist this time around. 6 | 7 | Important note: the Core Team has recently decided to have an extended beta for the Edition, which means the final release will be 1.31 on December 6. So we have 4.5 months to make progress before presenting our work to the world — definitely enough time to make some really meaningful progress! 8 | 9 | - Introduction and plan for the meeting 10 | - Quick rundown of the current state of affairs 11 | - Strawman proposal for goals and structuring 12 | - Goals 13 | - Great pitch for the new web site 14 | - Documentation!!! 15 | - Solid answers to: 16 | - “So you want to write an (async?) web server in Rust…” 17 | - More like this? 18 | - Ecosystem assessment, documentation, and improvements 19 | - Guidelines for networking-related libraries, e.g. approach to TLS 20 | - Subgroup structuring 21 | - Async: futures/async/await 22 | - Protocols: http (1/2), grpc, thrift, … 23 | - Service bindings: rabbitmq, redis, kafka, s3, etc 24 | - Middleware: Tower and related 25 | - Web apps: Flask/Sinatra-level “framework” bringing some of the above together 26 | - Guidelines: cross-cutting group developing best practices for networking libraries in Rust 27 | - How to approach the web site 28 | 29 | ## Intro 30 | 31 | - Roster implies no commitment; please add yourself 32 | - aturon leading discussion, pauses for discussion will be available (lots of people here!) 33 | - Please follow up later on non-urgent issues 34 | - What is this WG? 35 | - Part of 2018 domain WGs 36 | - Will be part of website calling out these domains 37 | - end-to-end story for specific areas 38 | - slow start due to tie-up with futures 0.3 and async/await 39 | - 19 weeks to put together best possible story 40 | - Can get a lot done — lots of interest in general and helping 41 | - Organization 42 | - Big tent with subgroups 43 | - Specific, concrete goals for the edition 44 | 45 | ## Current State 46 | - Sync 47 | - absolute basics in std (sockets) 48 | - assortment of crates providing additional functionality 49 | - including sophisticated web frameworks (e.g., Rocket) 50 | - Async 51 | - mio/tokio/futures 0.1 stack 52 | - currently used in production 53 | - various libraries around this 54 | - major deficits in ergonomics/readability/etc vs. async/await 55 | - alpha futures 0.3 56 | - async/await support included 57 | - active work on compat layer to integrate with futures 0.1 (and tokio) 58 | - middleware stack, Tower 59 | - relatively young 60 | - under development by Bouyant (Tokio/Hyper maintainers amongst others are employees) 61 | - assortment of protocol impls and service bindings (but no comprehensive view) (sync & async) 62 | - assortment of web frameworks, simple ↔ complex, nightly ↔ stable 63 | - and new ones being developed 64 | - Summary: There are many pieces, no polished whole 65 | - Newcomers are intimidated, rapidly shifting ecosystem 66 | - #1 goal: Build cohesive community to increase clarity/quality in ecosystem 67 | - Questions: 68 | - (stephanbuys) Don’t forget about packets (lower level than sockets): Probably non-goal for 2018, but goal for WG in general 69 | - (degausser) as an aside having strong defintions of words like “low-level” and “protocol” will be necessary when subgroups com together 70 | - (geal) Part of ecosystem directly builds on mio (w/o tokio) 71 | - (artemis) Building cohesion while keeping flexibility: addressed later 72 | - (skade) Accessible documentation is lacking: will be working on it 73 | - (jsgf) Cleanup/removal/deprecation for outdated code: 74 | - crates no longer considered best practice 75 | - pollution from old docs etc 76 | - (rolf) lack of clarity around interaction with language features (sync primitives, lifetimes); no docs 77 | - (crlf0710) database service async access 78 | - (jsgf) C++ and Rust in same process with their own event loops 79 | - pass control/events between them 80 | - perhaps share them (for example implement folly::Executor for tokio::Executor so that C++ code can spawn work into a Rust threadpool) 81 | - (erickt) Exploring how compiler can help w/ async awareness (e.g., mutex locks across await) 82 | - Please open issues on https://github.com/rust-lang-nursery/net-wg/ liberally 83 | 84 | ## Goals/Structure 85 | - Great pitch for the new web site 86 | - Documentation!!! 87 | - Solid answers to: 88 | - “So you want to write an (async?) web server in Rust…” 89 | - More like this? 90 | - Ecosystem assessment, documentation, and improvements 91 | - Guidelines for networking-related libraries, e.g. approach to TLS 92 | 93 | 94 | - Overall basis is to focus on end-to-end experience with specific tasks 95 | - Proposing a structure to get traction in setting/achieving goals 96 | - Async: futures/async/await 97 | - Protocols: http (1/2), grpc, thrift, … 98 | - Service bindings: rabbitmq, redis, kafka, s3, etc 99 | - Middleware: Tower and related; more? 100 | - Web apps: Flask/Sinatra-level “framework” bringing some of the above together 101 | - Guidelines: cross-cutting group developing best practices for networking libraries in Rust 102 | - Questions 103 | - *Scope*: Including sync & async with web apps & protocols 104 | - Protocols, Middleware are possibly too broad 105 | - Focus on framing around library development vs. applications — focus on core things (RPC, queue, db) but not high-level application design? 106 | - e.g Kafka might not be critical to most incoming users, whereas HTTP/TLS is 107 | - Common guidelines for protocol impls 108 | - This WG is not focused on taking ownership, rather providing guidance and documentation 109 | - focus on strong relationships with existing maintainers 110 | - Coherence of underlying infra is critical to maintain interop 111 | - “The common intersection between all crates in the ecosystem is the stdlib, so IMO when possible crates should make an effort to use only the stdlib" (tomaka) 112 | - Desire for today is overall, rough, consensus on structure & some sense of top level goals 113 | - Minimum bar for 2018: 114 | - Far more documentation around navigating network ecosystem 115 | - (at least one) really solid story around basics of network apps 116 | - assortment of web frameworks makes getting started confusing 117 | - Docs on when/where to use async 118 | - async/await will not be stabilized by 2018 release 119 | - aturon will open issues on net-wg tracker, async discussion 120 | - all-hands style meeting next week 121 | - new doodle poll will be sent out 122 | -------------------------------------------------------------------------------- /meetings/2018-08-03.md: -------------------------------------------------------------------------------- 1 | 2 | Agenda 3 | - Work through https://github.com/rust-lang-nursery/wg-net/issues/24 and https://github.com/rust-lang-nursery/wg-net/issues/35 4 | - Please read these threads and leave comments in advance of the meeting 5 | - Goal: arrive at rough consensus for the preliminary vision and structure of the WG 6 | - I expect this to take most of our meeting time! 7 | - Notes 8 | - End goal: Have a high level vision for structuring the WG. 9 | - Arrive at a rough consensus at the end of the meeting 10 | - 2018 vision 11 | - What is the scope of the changes? Language or Ecosystem 12 | - Depends on the end results. 13 | - Async foundations involve language change 14 | - Language changes not scheduled for 2018 shouldn’t be considered. 15 | - Deployment story valid for this WG? 16 | - Question of resource prioritization 17 | - How much work would be accepted to get things like OpenSSL and musl on the official docker image. 18 | - Ring is a problem 19 | - A branch started in December is close to allowing multiple versions to be linked? https://github.com/briansmith/ring/pull/619 20 | - Big companies generally have their own internal base images to build off of. 21 | - Maybe have docs on how to set it up with an example image. 22 | - Getting rust to build in a reproducible, secure manner across OSes 23 | - Important to not just wg-net 24 | - Strawman proposal: https://github.com/rust-lang-nursery/wg-net/issues/24#issuecomment-409081766 25 | - Not included in the strawman: 26 | - Ecosystem foundations don’t talk about integrating the existing ecosystem with async rust 27 | - Web foundations is good, but we need a high level story for other use cases 28 | - Some issues regarding the web context: 29 | - There’s a lot in terms of the web context, but it doesn’t work together. 30 | - Unclear decision making interms of low and high level abstractions. 31 | - Too much concern into the request response paradigms, which ignores other use cases 32 | - “Web foundations” is intended to focus n the coherence/compat of the web ecosystem. 33 | - Not sure of the vision for web in rust in general. What does it entail? Components? Web frameworks? 34 | - There is disconnect between tokio and threads. 35 | - No coherent story for managing contexts in a generic way. 36 | - think go contexts, .net execution contexts, jai's implicit context etc. 37 | - Contexts should work in both async and sync rust code. 38 | - Some form of example guide for getting started with async IoT in rust with good patterns highlighted. 39 | - Ecosystem survey: 40 | - what’s the approximate scope? 41 | - If multiple crates cover the same functionality, how should that be handled. 42 | - Good interoperability between libraries and language elements are helpful across most if not all of the domains of interests that were mentioned on these issues 43 | - Web is an important story to get right 44 | - Having a clear “End to End” goal is important. 45 | - Focus on documentation. 46 | - Start building the website (which website) 47 | - and writing docs for different use cases. 48 | - The holes in the ecosystem will show up when doing this. 49 | - Have reasonably clear “final deliverables” 50 | - websocket support would be a way to address non request-response oriented protocols. 51 | - Guides as deliverables 52 | - How to reconcile this with not having official defacto libraries. 53 | - Should we avoid “picking a winner” by making an official recommendation? 54 | - Proposed change to the vision: 55 | - Async foundations 56 | - IoT/embedded foundations (Focus on networking and not embedded in general) 57 | - Web foundations 58 | - Ecosystem pillar can be an open-ended/undirected ecosystem-focused driven by two particular domains of use. 59 | - Lots of opportunity in the data plane, how should that be addressed? 60 | - Documentation for different audiences. 61 | - Quick getting started style guides 62 | - In-depth understanding of foundational components. 63 | - It’s a lot more effective to shoot for a rough overall use case rather than trying to do completely open-ended doc/ecosystem work 64 | - Finish building and shipping async seems like a separate effort 65 | - A good overview for async deliverables can be gleaned from the contents of https://aturon.github.io/apr/ 66 | - Everything doesn’t need to be end-to-end, but should have a proper deliverable. 67 | - WG has low level usecases and high level usecases and each is being represented by a concrete example. 68 | - Strawman proposal for the organizational structure of the WG 69 | - Have two “point people” for each pillar. 70 | - They will lead/coordinate 71 | - Have two for availability and have different opinions. 72 | - WG members will gravitate towards one of these main areas of work. 73 | - Each sub group can work out its own way of setting a more detailed granular vision. 74 | - Leads will have a regular meeting to help coordinate the different efforts. 75 | - This is a repetition of the team structure followed in the Rust project. 76 | - Leads should be picked by interest and availability. 77 | - Proposed leads: 78 | - async foundations: cramertj + MajorBreakfast 79 | - Formalizing what is already in place. 80 | - Embedded foundations: Nemo157 + Ikurusa 81 | - Web foundations: aturon + yoshuawuyts 82 | - Once the leads are settled, a signup sheet for individual pillars will be available. 83 | - Should debug/introspection/tooling be it’s own pillar? 84 | - Should probably flow from the different useases/pillars 85 | - Very important 86 | - How much time is required of the lead? 87 | - Depends on how much help is coming from the sub group itself. 88 | - leads can also rotate over time. 89 | - There might be an abundance of interest in web, but embedded might be an issue. 90 | - What happens next: 91 | - aturon follows up with the leads to help firm up logistics. 92 | - He will send an email + a note on how to sign up for sub groups. 93 | - Fine to do multiple, shift overtime/etc. 94 | - Basically a mailing list to make sure the sub group can organize things. 95 | - We’ll aim for each of the three pillars to flesh out a more concrete picture of their end deliverables over the next week or so. 96 | - Most likely that the leads will have regular meetings open for anyone to join in. 97 | - The sub groups should be largely independent in organization but with regular cross-cutting check-ins. 98 | -------------------------------------------------------------------------------- /meetings/2018-08-31-net-wg-leads.md: -------------------------------------------------------------------------------- 1 | # Net WG Lead Meeting #1 2 | **Maximum duration**: 60 minutes 3 | **Date picker**: https://doodle.com/poll/xttrxdp3f8xukfad 4 | 5 | # Objective 6 | 7 | This will be the first meeting Net WG meeting since we kicked off the different sub-working groups. Let’s figure out ways we can keep momentum going, and effectively communicate with the wider Rust community. 8 | 9 | # Agenda 10 | 11 | *Feel free to add more items that you think are important.* 12 | 13 | 14 | 1. General Introduction - 5m (Yosh) 15 | 1. Agree someone to take notes 16 | 2. Check if any agenda items are missing 17 | 2. WG Status - 25m 18 | 1. Web - 5m 19 | 1. Progress 20 | 2. Goals 21 | 3. Issues 22 | 2. Async - 5m 23 | 1. Progress 24 | 2. Goals 25 | 3. Issues 26 | 3. Embedded - 5m 27 | 1. Progress 28 | 2. Goals 29 | 3. Issues 30 | 3. Blog - 10m 31 | 1. Content planning? 32 | 4. Newsletter ([link](https://github.com/rust-lang-nursery/wg-net/issues/51)) - 10m 33 | 1. Agree on date 34 | 2. Content planning? 35 | 5. Schedule next meeting - 5m 36 | 1. Have a doodle poll ready 37 | # Minutes 38 | 39 | Attendees: yoshuawuyts, lkurusa, MajorBreakfast, Nemo157, cramertj 40 | 41 | - Brief overview from each WG (goals, progress and blockers; to have a shared sense of what’s going on) 42 | - WG-Web 43 | - Two goals since kickoff: 44 | - to build out a learning web framework (tide) 45 | - to investigate the web ecosystem and help out where pieces are missing 46 | - aturon primarily responsible for the former, yoshuawuyts for the latter 47 | - Blog posts for tide in progress, placeholder repo at https://github.com/rust-net-web/tide 48 | - Two issues for ecosystem investigation: 49 | - https://github.com/rust-lang-nursery/wg-net/issues/44, a call for example web projects to help inform what folks are running into 50 | - https://github.com/rust-lang-nursery/wg-net/issues/54, to help document missing parts of tokio 51 | - Inaugural WG-Web meeting next Thursday 52 | - WG-Async 53 | - New methodology for testing, the `futures-test` crate. Contains various helpers to make writing tests for 0.3 futures easier. Will be shipped as part of the upcoming alpha 4 of the `futures` crate. 54 | - Disruption with the sudden changes to the `std` `Pin` APIs. Came as a surprise, will also be fixed in the alpha 4 release. 55 | - Work on the compatibility layer, blog post is ready. `tokio-async-await` was released by the tokio team, good opportunity for some collaboration; maybe move all the compatibility stuff to this crate. 56 | - cramertj has started discussion about a `FusedFuture` trait that should make it possible to check whether a future has already completed and produced its value ([https://github.com/rust-lang-nursery/futures-rs/issues/1219](https://github.com/rust-lang-nursery/futures-rs/issues/1219)). PR ready. 57 | - Easy to support with `async` produced futures as they already track this state for memory safety, 58 | - Difficult to decide on the best implementation strategy, discuss on the issue. 59 | - boats has been reworking the pin types, but has hit some stumbling blocks in method resolution, so that’s stuck at the moment ([https://github.com/rust-lang/rust/issues/53843](https://github.com/rust-lang/rust/issues/53843)). 60 | - cramertj has been working on a PR for a new “scoped tasks” feature, similar to crossbeam’s, that would let you spawn futures that could reference your local stack. 61 | - cramertj has also been giving some thought on how to solve the issue of wanting to return early from a function that returns an async block; finding it quite common in fuchsia so been exploring options there 62 | - discussion on the wg-net repo about the async programming book 63 | WG-embedded 64 | - nemo mostly been working on https://github.com/nemo157/embrio-rs - a `no_std` compatible cross-target executor + futures targeted Hardware Abstraction Layer (HAL) for interacting with micro-controller peripherals. 65 | - nemo major blocker is lack of async/await in no-std environments. 66 | - nemo async/await is also needed for traits in HAL because it’s basically a big collection of traits. 67 | - nemo blog post + docs are in the works. 68 | - nemo been meaning to have more discussion about standardizing async IO traits (https://github.com/rust-lang-nursery/wg-net/issues/53) + traits for datagram protocol like UDP and bring up ideas around removing the `poll_*` layer and having traits that return futures directly. 69 | - lkurusa got hold of a bunch 16 ARM controllers - hoping to use them to pinpoint problems with rust. 70 | - lkurusa released cgroups crate — also been attending the embedded WG meetings. 71 | 72 | Blog 73 | 74 | aturon emphasised that we do have a blog, and we should probably make more use of it 75 | discussion on possible blog posts/plan for content 76 | MajorBreakfast: what about encouraging framework authors to present their framework in a blog post, we could come up with some kind of limited length format that could be followed 77 | MB: it would also mean that the authors could influence directly what is written, instead of someone else describing their work it’d be the authors themselves 78 | lkurusa: could we agree on a set of questions/bulletpoints beforehand 79 | MB: create an issue for it and agree on a semi-flexible style for the posts 80 | MB: Limit length so that we don’t get tutorials, but instead a glance at what the project’s are about 81 | yoshuawuyts will open issue, MB is lacking in spare time to followup ATM 82 | yoshuawuyts: aturon mentioned wanting to blog about tide a bunch, but not sure where the posts are intended to go 83 | 84 | Newsletter 85 | 86 | https://github.com/rust-lang-nursery/wg-net/issues/51 87 | similar to the embedded WG, regular newsletter with what’s been happening 88 | suggestions to post to internals and blog (for an easily accessible archive) 89 | target date for first issue: 2018-09-12 90 | -------------------------------------------------------------------------------- /meetings/2018-09-06-net-web-wg.md: -------------------------------------------------------------------------------- 1 | # Net Web WG Meeting #1 2 | **Maximum duration**: 60 minutes 3 | **Date picker**: https://doodle.com/poll/nmi44m6hezvbgd4g 4 | 5 | # Objective 6 | 7 | This will be the first meeting Net Web WG meeting since we kicked off the working group. The goal is to talk about the vision for the working group for the next few months, and find concrete goals we can achieve. 8 | 9 | # Agenda 10 | 11 | *Feel free to add more items that you think are important to discuss.* 12 | 13 | 14 | 1. General Introduction (Yosh) - 5m 15 | 1. Agree someone to take notes 16 | 2. Check if any agenda items are missing 17 | 2. Vision (Aaron) - 15m 18 | 3. Tide (Aaron) - 10m 19 | 1. Status so far 20 | 2. How to participate 21 | 4. Micro Projects (Yosh) - 10m 22 | 1. Status so far 23 | 2. How to participate 24 | 5. Survey (Yosh) - 5m 25 | 6. Blog Posts (Yosh) - 5m 26 | 1. Framework highlights 27 | 7. Newsletter ([link](https://github.com/rust-lang-nursery/wg-net/issues/51)) - 5m 28 | # Minutes 29 | - Vision of the WG(@aturon): 30 | - https://rust-lang-nursery.github.io/wg-net/web-foundations/ 31 | - There are a lot of crates for working with web, but no one has looked at the *big-picture*. 32 | - Eg: Making sure various crates fit well, standardized interfaces, locating missing features. 33 | - General feeling of production users of rust-web is that the ecosyste is immature. Hard to figure out what the pieces even are, let alone how to put it together. 34 | - Compounded by async-rust flux. 35 | - Goal: Improve state of affairs, while being very open and collaborative. 36 | - Vision document: focused on what's feasable for the rest of the year 37 | - Two related efforts: "Top down", "Bottom up" 38 | - Top Down: 39 | - Building a web framework (Tide) based almost entirely on external crates 40 | - A way to drive overall work, set up clear needs and have a useful artifact at the end. 41 | - Strive to build all new functionality in re-usable crates which are not specific to the framework 42 | - Use this as a way to standardize on interface and make specific recommendations on what crates to use, etc. 43 | - Plan on writing this as a small book in addition to the framework itself. 44 | - This will go through each aspect of web development and explain the ecosystem around it. 45 | - Bottom up: 46 | - Discovering and trying to use existing crates, and writing small experiments and examples 47 | - Driven in part by surveys and community-provided examples and requests. 48 | - These two should come together at some point, but currently are separate efforts 49 | - By the end of 2019,there should be significantly more documentation and guidance around rust-web. 50 | - A lot of improvements should have been made in the crates used in the ecosystem. 51 | - Have a new framework built. 52 | - Questions: 53 | - How to avoid confusion with adding a new framework? 54 | - Tower is for a general abstraction for services. 55 | - Idea is to use Tower to build Tide 56 | - Make a distinction between providing a service vs a full fledged framework. 57 | - Want to contribute to crates like tower-service, hyper, http, url etc. 58 | - Rocket, Gotham, warp, tower-web are existing frameworks and Tide will be adding to the list. 59 | - Hopefully, by doing this in a component-driven way, we can help all those frameworks share more code. 60 | - (@rolf) looks like we are looking for some core abstraction(s) to settle on. 61 | - Status of Tide/How to participate(@aturon): 62 | - Fundamental parts of a framework need to be built (Before external crates can be used). 63 | - A start on a blog series: 64 | - ([+Rising Tide: building a modular web framework in the open](https://paper.dropbox.com/doc/Rising-Tide-building-a-modular-web-framework-in-the-open-LEaKJbittpeJSi4OacsGH) ) 65 | - Trying to outline the goals of a web framework in general. 66 | - Take a look at those fundamental pieces. 67 | - First two: The service abstraction and routing: 68 | - Service abstraction: 69 | - Service abstraction is what @rolf was alluding to. 70 | - What rack provides in the ruby world. 71 | - A general way of saying: "A function that consumes requests and produces responses." 72 | - Can be pretty subtle. 73 | - Goal: Decouple web app/frameworks from web servers. 74 | - Most frameworks in rust use hyper directly. 75 | - actix is the exception which uses its own server. 76 | - With the service abstraction, a "many-to-many" relationship possible between servers which consume underlying protocol and frameworks which can help you write services. 77 | - Different from the Service trait in hyper. 78 | - Should ideally exist in a standalone crate 79 | - @seanmonstar: effort already exists: 80 | - generalizing hyper into the http crate and tower-service to be the rack/wsgi/servlet of rust. 81 | - @aturon: get the WG more involved and get community buy-in on standardizing. 82 | - Once this abstraction exists, a framework is a fancy way of writing services. 83 | - Helps factor out HTTP and other concerns. 84 | - Routing: 85 | - Note: some frameworks like warp don't need routing as a separate concern. 86 | - Many possible approaches. 87 | - @seanmonstar: 2) Document the "canonical" approaches that fit rust well. 3) Choose one of them for Tide and build it such that it can be shared. 88 | - Routing is opinionated. At the same time there are already a couple of clear "styles". 89 | - The implementation can be standardized. 90 | - (@aturon) these are the pieces put together so far. Working on a blog series. Hoping that this exploration and documentation can be done in an open way from the start.: 91 | - First steps: a bunch of digging and will be writing thoughts. 92 | - Hoping that after the first couple of posts, to get more people involved. 93 | - Will be opening issues for some of these questions. 94 | - Will be looking for collaborators. 95 | - For now, just let me know if you're interested. 96 | - (@Carl Lerche): pushing on BufStream to standardize the body: 97 | - Combo of Service, http Request/Response/BufStream is going to be tower-http 98 | - BufStream is moving to tokio-buf 99 | - Once this work is done, work will start at integrating tower and these traits in hyper and warp 100 | - tower-web also includes a middleware trait to push on those concepts. 101 | - Working with actix 102 | - If warp + actix move to Tower that makes the ecosystem. 103 | - (@thramp): It is pretty useful to have a separate function that handles the routing logic, while a separate function is responsible for the actual request handling. 104 | - (@aturon): Hope to use the WG to drive help from the community for these topics. 105 | - Micro projects(@yoshyawuyts): 106 | - Tracking issue for the bottom up work: 107 | - https://github.com/rust-lang-nursery/wg-net/issues/45 : 108 | - Come up and implement small projects in order to improve the status quo around web rust. 109 | - Activity has slowed down somewhat recently. 110 | - Not sure if the idea behind it was explained well. 111 | - Can the wg-net blog draw more attention to the effort? 112 | - Can quest issues help? 113 | - Crowd sourcing the kinds of examples people would like to see in the web space. 114 | - Idea for a blog post: explain the effort nd ask for both crowdsourcing of examples and for participation in implementing them. 115 | - Survey (@yoshyawuyts): 116 | - It'd be great to have a survey to ask people how folks are using rust for web programming. 117 | - Not sure where to start. 118 | - @rolf: how many people can be reached by the survey? 119 | - @aturon: the rust survey hits 5k people every year. CLI WG survey got at least several hundred. 120 | - @rolf: making easy to fill with checkboxes and radio buttons instead of free form answers will help gather a lot of information.: 121 | - What are the pain points? 122 | - Figure out people's experiences. 123 | - What modules they use, what they think is good, what they think is less good. 124 | - Open a new issue for a general web survey. 125 | - Blog posts (@yoshyawuyts): 126 | - We have some posts in works. 127 | - Do these posts go on the web-net website or personal websites? 128 | - WG website. 129 | - Talk to framework authors about their frameworks. 130 | - Create tracking issue: 131 | - Discuss good questions and get authors involved. 132 | - Newsletter(@yoshyawuyts): 133 | - Date for shared newsletter confirmed: 12 September. 134 | - Posting to internals.rust-lang.org 135 | - Tracking issue: https://github.com/rust-lang-nursery/wg-net/issues/51 136 | -------------------------------------------------------------------------------- /meetings/2019-02-14.md: -------------------------------------------------------------------------------- 1 | ## Working Group Updates 2 | - Status updates 3 | - tide 4 | - docs 5 | - All-hands recap 6 | - Add WG agenda items here… 7 | - Can we get alignment between Tide’s middleware and Tower’s middleware? 8 | - Missing gaps in the ecosystem 9 | 10 | ## Revamping the structure of the WG 11 | 12 | - Initially structured as three “sub” WGs: 13 | - async 14 | - embedded 15 | - web 16 | - Proposed structure 17 | - network foundations (lang/compiler/`std`) 18 | - network ecosystem 19 | 20 | ## Survey review 21 | 22 | - Biggest takeaway: lack of documentation and examples is a major problem in the Rust async world right now 23 | - People also want a “one true framework” / more obvious default choice 24 | - Still lots of gaps in the web ecosystem 25 | - client libraries for message queues 26 | - async database drivers 27 | - Summary post 28 | - aturon wants to review detailed responses to make an “ecosystem TODO list” 29 | 30 | ## Update on the state of networking 31 | 32 | - Rust team All Hands 33 | - 3 sessions on Tide 34 | - mostly introducing people to Tide 35 | - some high-level API review 36 | - CSRF issues 37 | - 3 sessions on async + futures 38 | - No decision yet on final `await` syntax, but some progress on process to get there 39 | - session on futures 1.0 👍 40 | - futures RFC is in FCP 41 | 42 | ## Tide 43 | 44 | - progress has been steady, even in absence of meetings 45 | - API Design notes 46 | - we’d like to explore different API designs outside of extractors 47 | - Tide could move to a more “layered” structure, where each endpoint is `async fn(RequestContext) - > Response`. 48 | - A branch + writeup are planned to explore this direction further 49 | - We’re thinking of moving to a highly iterative approach, where we can release new Tide versions early + often 50 | - Create a split between “core” functionality, and ergonomics that can be layered on top 51 | - The plan will be laid out more concretely in issues/RFCs 52 | 53 | ## Async 54 | 55 | - Concerns about how the process around futures and async/await has progressed — there’s a large disconnect between the public github threads and private discussions amongst team members, which feels bad for everyone 56 | 57 | ## Middleware ([http-service](https://docs.rs/http-service/0.1.1/http_service/) + [tower](https://docs.rs/tower/0.0.1/tower/)) 58 | 59 | - Lots of overlap between what these two crates are trying to do 60 | - The http-service crate is intended to be framework-neutral, and collaboration is super important there 61 | - However, there’s a lot of detail work to figure out how to fit this together in a way that works for Tide, Tower, and others -------------------------------------------------------------------------------- /meetings/2019-02-21.md: -------------------------------------------------------------------------------- 1 | ## Working Group Updates 2 | - Recurring meeting slot (poll) 3 | - Finalized to Thu 10AM-11AM CST 4 | - Tide issue triage 5 | - Initial triage on 2019-02-22 10AM - 11AM CST 6 | - Once initial triage is done, recurring triage will occur during the weekly meetings 7 | - Status updates 8 | - tide 9 | - @Aaron T submitted a new PR refactoring the internals of tide to use the new http-service crate 10 | - for http-service, the goals are: 11 | - to provide an interface that is not tied in to any particular framework or server 12 | - to work with futures 0.3 directly 13 | - to avoid generics as much as possible, to keep the type system aspects relatively easy 14 | - WG structure 15 | - `rustasync` will be the umbrella org for the rust asynchronous ecosystem with two major focuses 16 | - One would be the async foundations which overlaps with the compiler team and works to add async features to the languages 17 | - The other will be async ecosystem, which focuses on the broader async ecosystem 18 | - Quoting @yoshua w : 19 | > being about networking, the scope of the async ecosystem WG would also include bindings to platforms, reactors, thread pools, and traits to bind them together 20 | 21 | ## Office Hours 22 | - Web WG is growing: Can we list the core areas of the “new” WG? 23 | - What is the most urgent area where help is needed? Tide? Core-Crates? 24 | - What other ways are there to help out except PRs? 25 | - What’s the timeline for the first version of Tide and how many people are currently working on it? 26 | - //Maybe an offtopic question: How would you position Rust/Tide vs. NodeJS and Go. What are the arguments you would tell a company/shop to use Rust/Tide instead of Node or Go? 27 | - Get a stable core framework up and running from which point we can start semver versioning. 28 | - The triage meeting happening tomorrow and the triage which will happen during the weekly meeting would be a great entry point for onboarding contributors. 29 | - Mentorship 30 | - Are there any plans for providing mentorship to new contributors? 31 | - Similar to the previous question, the triage meetings would be a great point to start the onboarding of new contributors. 32 | - How would this be structured? -------------------------------------------------------------------------------- /meetings/2019-02-28.md: -------------------------------------------------------------------------------- 1 | ## Working Group Updates 2 | - Status updates 3 | - tide 4 | - Outcome of the triage from last Friday. 5 | - Need to discuss owner structure of crates and who is able to update/publish them. 6 | - Figuring out to make the whole WG as a maintainer of a crate: `cargo owner --add "github:rustasync:maintainers"` 7 | - Merged @Bastian G `http-service-mock` crate 8 | - @V B Looked into session management (mainly Rocket, actix-web and tower-web) and how we could implement it in tide. He also looked into URL generation. Django and Flask are using a stringly typed API, which we want to avoid 9 | - @Sendil K proposed to be able to serve static files (issue) 10 | - Gaps in the ecosystem 11 | - [2019-02-27 Web Ecosystem Gaps](https://paper.dropbox.com/doc/2019-02-27-Web-Ecosystem-Gaps--AbDiGEkEgke46uLrPDgEOn6ZAg-1DSQhREQVJYGirBelosBY) 12 | - Going through the survey points. This document is a great starting point for anyone who wants to contribute to the ecosystem 13 | - Creating a guide like tokio doc-blitz 14 | - Crates could be linked to [AreWeWebYet](http://www.arewewebyet.org/)? 15 | - Discussion of how to point to the next priority to work on and where to share progress. Libraries are not synced with the latest progress (like futures 0.3) and people are waiting for things to finalize and stabilize 16 | - Update areweasyncyet to point to which futures version is supported 17 | - Link areweasyncyet to async-book 18 | - Summary of the discussion: “we have a consensus that for now we should't engage in building a new list, we shouldn't put out a call for implementations, but we should start making futures 0.3/1.0 projects more discoverable” 19 | - Async WG transition updates 20 | - wg-net site 21 | - rust-lang.org (team repo) 22 | - Discord channel, wg-net repo and website still need to be moved to the new org structure. @Aaron T is needed for this because of admin rights 23 | - Discrod channel should be under “domain working groups” in the future, but needs to be clarified. @yoshua w is coordinating it. 24 | - Joint meeting with async foundation wg is planned, and more check ins in the future 25 | - Blog post or primer on how to get involved with the group with details 26 | 27 | ## Office Hours 28 | - Extractor or Resource download option for the tide ([PR]( https://github.com/rustasync/tide/pull/126)) 29 | - PR is stalled, suggestion to treat static file serving as a separate concern and implement it into the middleware -------------------------------------------------------------------------------- /meetings/2019-03-07.md: -------------------------------------------------------------------------------- 1 | ## Working Group Updates 2 | - Status updates 3 | - tide 4 | - Core idea is to create the “smallest” core API as possible 5 | - The goals are: 6 | - Taking care of http-related concerns at “signature” level 7 | - Working with application types instead of http types 8 | - Current downsides of the extractor setup are dealing with wrapper types, some magic impls of the Endpoint trait which makes it overall hard to use and understand 9 | - @Aaron T is working on revamp to make it easier to use and understand 10 | - The goal is to write endpoints directly and extract data within the body instead of having various Endpoint impls for extractor arguments 11 | - Extractions (could) happen inside the endpoint body instead of getting passed as parameters. However, the seperation of http and application would weaken 12 | - Using attribute macros to extract parameters to keep the function bodies “app native” 13 | - @Aaron T will write up a lengthy proposal for this change (proposal). Generally great feedback from the working group 14 | - wg transition 15 | - We have rustasync GitHub handle 16 | - We fixed the blog and the urls 17 | - Still missing: rust-lang.org, discord and twitter, rustasync 18 | - Website: @yoshua w 19 | - Twitter: @Aaron T 20 | - Discord: @Aaron T 21 | - rustasync: Will be an issue on GitHub 22 | - Need to give access rights to team members to transition ownership from private crate to rustasync 23 | - arewewebyet 24 | - Looking for maintainers and doing active curation within the team 25 | - Probably takes 10 minutes a week to keep it updated and curated 26 | - Long term vision: AWWY could be a key role in communicating, together with the working group and areweasync yet 27 | - areweasyncyet 28 | - Constant updates, need to get upsuper joining the next meeting 29 | - [2019 roadmap](https://github.com/rustasync/team/issues/96) 30 | - Read it and give feedback 😉 31 | - 6 week sprints 32 | - WASM WG is starting with 6 week sprint cycles (again) 33 | - Use this also for our working group to plan work in terms of time and setting goals 34 | - Having a road map according to the 6 week cycle 35 | - Creating an issue with first thoughts - [https://github.com/rustasync/team/issues/96](https://github.com/rustasync/team/issues/96) 36 | - Issue triage (org | tide) 37 | - No time left, first point on the agenda for next meeting -------------------------------------------------------------------------------- /meetings/2019-03-14.md: -------------------------------------------------------------------------------- 1 | ## Working Group Updates 2 | - Status updates (10 mins) 3 | - tide 4 | - Updates on the [route-match algorithm](https://github.com/rustasync/tide/issues/141). 5 | - areweasyncyet 6 | - Upsuper won’t make it to the meetings because of time difference. Goals would be to add a bit automation to keep things updated. Not much plans otherwise, so suggestions are welcome. 7 | - arewewebyet 8 | - A few curation PRs to prune unmaintained crates, steady progress 9 | - List of all “are we xy yet” is at the MozillaWiki: https://wiki.mozilla.org/Areweyet 10 | - romio + juliex 11 | - Moving both repos to the org soon, have to find the time to do that 12 | - async foundations 13 | - http://smallcultfollowing.com/babysteps/blog/2019/03/01/async-await-status-report/ 14 | - Discord and twitter still need to be updated; time is (as always) very limited 15 | - In talks to schedule a regular checkin meeting wit the async foundations WG 16 | - asnyc foundation WG also open to have sprints 17 | - 6 week sprints (25 mins) 18 | - https://github.com/rustasync/team/issues/96 19 | - Helpful to define metrics (“we support X after this sprint”…) 20 | - After the sprint we want to have a small and well defined example app 21 | - The tide rewrite should have been merged 22 | - Finished and stabilized the “core” (PR/issue need to define what exactly is included in the core) 23 | - Generally raising concerns about the direction of the WG and tide, which will be talked at another time (https://github.com/rust-lang/rfcs/pull/2657#issuecomment-471643874) 24 | - The extractor interface change needs to happen in this sprint as well, which is a blocker for future work on the middleware 25 | - Another sprint goal is to come up with a websockets design 26 | - Issue triage ([org](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+archived%3Afalse+user%3Arustasync) | [tide](https://github.com/rustasync/tide/issues/))(25 mins) 27 | - https://github.com/rustasync/tide/issues/152 28 | - Logging vs Tracing: Logging prio 1 29 | - Solution (and talked about previously) was to use a log middleware create which just calls the log macros instead of setting up a logger 30 | - Moving session management (https://github.com/rustasync/tide/issues/9) to the core 31 | - Proposed “documentation” label 32 | 33 | ## Office Hours 34 | - No office hours this week. -------------------------------------------------------------------------------- /meetings/2019-03-28.md: -------------------------------------------------------------------------------- 1 | ## Working Group Updates 2 | - Status updates 3 | - tide 4 | - Discussions around @Aaron T PR about the big rewrite. Some concerns about declerative vs. imperative and passing the whole state in every route. Examples should clarify the concerns soon. 5 | - areweasyncyet 6 | - maintenance mode and just needs updates whenever features are getting stabilized 7 | - arewewebyet 8 | - PR with updated WASM topic 9 | - We still need to figure out access writes to close the currently 11 open PRs Fixed 10 | - Changing engine from jekyll to cobalt, but not a priority right now 11 | - Cleanup is still in progress 12 | - romio + juliex 13 | - @yoshua w put out a new release for both last week 14 | - Juliex now as a thread pool initialization hook; useful for setting up TLS 15 | - Romio exposes new contructors (like TryFrom 16 | - https://github.com/yoshuawuyts/async-ready 17 | - https://github.com/yoshuawuyts/async-datagram 18 | - Issue triage (org | tide) 19 | - skip because of the blocking rewrite PR which needs to be merged first 20 | - Other WG agenda items 21 | - Start putting async-book and futures on the weekly agenda 22 | - Brainstorm async-book chapter ideas so people can pick them up and write about them 23 | - Disucssions around keeping track of async realted topics; hard to keep track of what’s floating around 24 | -------------------------------------------------------------------------------- /meetings/2019-04-04.md: -------------------------------------------------------------------------------- 1 | ## Six-Week Sprint 2 | - End date: 2019-05-02 (six weeks) 3 | - Sprint goals 4 | 5 | ## Working Group Updates 6 | - Status updates 7 | - futures 8 | - Transition to 0.3 is mostly done 9 | - Cleanup the “disabled” parts of the code base still needs to happen 10 | - AsyncSeek trait still needs to be added (besides other features) 11 | - Getting more users to try it out is a key to figure out what is still missing 12 | - There are still a few broken doc links which need to be fixed 13 | - romio + juliex 14 | - Not much happened in the last week 15 | - A new bug was filed (link) and being triaged 16 | - async rust book 17 | - Hold off until Futures are stabilized (Just the Futures API, not all of AsyncRead, AsyncWrite etc.) 18 | - This might happen soon though 19 | - arewewebyet 20 | - WASM topic updated 21 | - All current PRs are merged 22 | - Current focus: content 23 | - Next topic will be infrastructure tasks 24 | - tide 25 | - @Aaron T will finish up the blocking rewrite PR asap 26 | - Other improvements (endpoint errors) will be outlined in a GitHub issue 27 | - Nested apps will be discussed in a future PR 28 | - Issue triage (org | tide) 29 | - Add WG agenda items here… 30 | - Add http-service to future agendas 31 | - Lets start each meeting with the Sprint Goals/Roadmap -------------------------------------------------------------------------------- /meetings/2019-04-11.md: -------------------------------------------------------------------------------- 1 | 2 | ## Six-Week Sprint 3 | - End date: 2019-05-02 (six weeks) 4 | - [Sprint goals](https://github.com/rustasync/team/blob/master/rfcs/0001-tide-roadmap.md) 5 | - Since the big revamp PR landed, people can pick up issues and working on them 6 | - Even if the async book is currently blocked, outlining chapters is helpful to bring book in a rough shape 7 | - Discussions around standardized middleware interface, work queues and non HTTP based protocols need to happen 8 | - Discussions around those topics should happen under the according issue to be able to track the progress 9 | - This sprint is more focused on “insiders”. Starting next sprint the goal is to bring more maintainers in 10 | 11 | ## Working Group Updates 12 | - Status updates 13 | - tide 14 | - The big [revamp](https://github.com/rustasync/tide/pull/156) is finally merged which makes the code easier to understand 15 | - @Aaron T cleaned up old issues; the current list is now be able to get worked on 16 | - The core is probably in a final state so it’s worth considering creating a new release and publishing a blog post 17 | - It’s also a great opportunity go get new people on board 18 | - Before that there still needs to be work done to make it more welcoming for newcomers to contribute 19 | - The open [RFC](https://github.com/rustasync/tide/issues/162) is going in this direction 20 | - How to handle “core”/ecosystem split, and Tide releases (see this [RFC](https://github.com/rustasync/tide/issues/162)) 21 | - The idea is to bring crates into a tide-x namespace once they gained mass adoption to support them “officially” 22 | - Outlining a process helps for communication and to have a guideline 23 | - Another idea is to create a middleware interface which could work across frameworks 24 | - The deadline should be by the end of this sprint, to get people on board and momentum going 25 | - Planning to bump the version to 0.1.0 (without a big announcement) so people can play around with the changes 26 | - Start formalizing a set of core maintainers to remove blockers in the future 27 | - futures 28 | - Lots of progress is being made lately ([issue](https://github.com/rust-lang/rust/issues/59725)) 29 | - Should be ready for stabilization in Rust 1.36 (in 6 weeks) 30 | - The Future crate is currently broken on nightly due to API changes (`&Waker` → `&mut Context<``'``_>` ([PR](https://github.com/rust-lang/rust/pull/59119)) 31 | - romio + juliex 32 | - Open [PR](https://github.com/withoutboats/juliex/pull/13) removes double boxing 33 | - Another open [PR](https://github.com/withoutboats/romio/pull/83) is adjusting to upcoming futures-preview changes 34 | - async rust book 35 | - nothing happened around this topic last week (due to futures stabilization) 36 | - Outlining chapters to figure out how the book will look like 37 | - arewewebyet 38 | - Content updates were being made 39 | - Issue triage ([org](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+archived%3Afalse+user%3Arustasync) | [tide](https://github.com/rustasync/tide/issues/)) 40 | - @Aaron T cleaned up a few issues so everything open should be able to get worked on -------------------------------------------------------------------------------- /meetings/2019-04-18.md: -------------------------------------------------------------------------------- 1 | ## Six-Week Sprint 2 | - End date: 2019-05-02 (six weeks) 3 | - [Sprint goals](https://github.com/rustasync/team/blob/master/rfcs/0001-tide-roadmap.md) 4 | - Roadmap needs to be updated with already completed items 5 | - Open PR which adds cookie middleware and it’s associated extension trait 6 | - We need to find a way to bring all extension traits into scope without manually add every one of them 7 | - Lots of open PRs and work around tide in the last week 8 | 9 | ## Working Group Updates 10 | - Status updates 11 | - tide 12 | - Work on various crates to be compatible with the latest futures API on nightly 13 | - tide 0.1.0 release 14 | - Lots of discussions around authentication, static files and URL generation which is also on the roadmap for this sprint 15 | - Experimental implementation for serving static files ([GitHub](https://github.com/tomhoule/tide-static-files)) 16 | - Dedicated issue for figuring out cross-framework middleware ([issue](https://github.com/rustasync/tide/issues/164)) 17 | - A path for that would be to find some least-common denominator trait for middleware, and then focus on developing cross-framework middleware 18 | - Discussion needs to happen around crates which add functionality to tide. Discussion will happen on the RFC thread ([issue](https://github.com/rustasync/tide/issues/162)) 19 | - futures 20 | - Big breaking change (Context + Pin projection on the streams traits) 21 | - Sink is now generic over its item, makes it possible to implement it multiple times for a single type 22 | - FutureObj is deprecated, need to be swapped out for Pin> (will have an alias) 23 | - async specifics might move behind a feature so that we can have a version that will compile on 1.36 when futures_api is stable 24 | - runtime 25 | - Crate was released earlier this week ([reasoning](https://blog.yoshuawuyts.com/runtime/) | [crate](https://github.com/rustasync/runtime)) 26 | - It abstracts romio+juliex, tokio and others in the future 27 | - It lives under the rustasync org 28 | - romio + juliex 29 | - no time for it this meeting 30 | - async rust book 31 | - No progress this week 32 | - arewewebyet 33 | - no time for it this meeting 34 | - Issue triage ([org](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+archived%3Afalse+user%3Arustasync) | [tide](https://github.com/rustasync/tide/issues/)) -------------------------------------------------------------------------------- /meetings/2019-04-25.md: -------------------------------------------------------------------------------- 1 | ## Six-Week Sprint 2 | 3 | - End date: 2019-05-02 (six weeks) 4 | - Sprint goals 5 | - One week away from the end of the sprint 6 | - Tide: Probably merging the Context PR is the only achievable goal, good progress in regards to session management though 7 | - Async book: Could finish the goals 8 | - Website goals seem to be done 9 | - Library ecosystem: Done as well 10 | - Preparing the next sprint: Some pre-thinking is needed ahead of the next meeting; formalize and communicate the project list on the agenda is also one important factor for next sprint 11 | - In addion we could have rough leads on each sub-project 12 | - Still need to update the discord channels and the [README](https://github.com/rustasync/team) 13 | - Yosh not attending 02/05 meeting 14 | 15 | ## Working Group Updates 16 | 17 | - Status updates 18 | - tide 19 | - Improved cookie support landed ([PR](https://github.com/rustasync/tide/pull/170)) 20 | - Great example of how to use middleware and context extensions 21 | - It extends Context with the ability to both read and write cookies 22 | - The middleware, after invoking the endpoint, then reads out the updated cookies and adds them to the response 23 | - Could code example to get familiar with Context and middleware 24 | - General very active in the last week, lots of discussions and new members 25 | - PR is coming up soon which does the crate split discussed last week 26 | - Need to workout a process for review and contribution, and when folks are allowed to merge 27 | - http-service: Returns now a future ([PR](https://github.com/rustasync/http-service/pull/21)), now we can work on this [issue](https://github.com/rustasync/http-service/pull/21) in tide 28 | - Breaking change to http-service-hyper that changes function signature (serve → run, serve_async → serve) 29 | - futures 30 | - futures_api is now stable in nightly 31 | - futures crate updated accordingly 32 | - expect a PR to put remaining unstable features in futures crate behind a feature flag, so that the crate can work on stable 33 | - runtime 34 | - Patched a bug where macros would fail 35 | - Quite popular, past 500 stars on GitHub 36 | - Created tracking issues for people to get involved ([link](https://github.com/rustasync/runtime/issues)) 37 | - romio + juliex 38 | - no updates 39 | - async rust book 40 | - Approaching cramertj and coming up with a plan next week 41 | - Plan is to move the book under the rustasync umbrella 42 | - arewewebyet 43 | - Removed outdated packages 44 | - Added two new topics: 45 | - asyncio: 46 | - tokio 47 | - futures 48 | - … 49 | - nodejs 50 | - neon 51 | 52 | - Issue triage ([org](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+archived%3Afalse+user%3Arustasync) | [tide](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+archived%3Afalse+user%3Arustasync)) 53 | - PR sign-off process 54 | -------------------------------------------------------------------------------- /meetings/2019-05-09.md: -------------------------------------------------------------------------------- 1 | ## Announcements 2 | - Aaron will take a break for a while; currently set for about a month 3 | - @yoshua w will take over the meetings for this time, with the help of @V B 4 | - Stable Futures set for release 1.36 5 | - Stable .await syntax set for release 1.37 6 | 7 | ## Six-Week Sprint 8 | - End date: 2019-05-02 (six weeks) 9 | - Last week was the end of the previous sprint; we didn’t kick off a new one yet 10 | - Reflect on past sprint 11 | - Sprint tracking didn’t go well 12 | - Milestones could help with keeping an up-to-date view of the sprint 13 | - Using GitHubs org board for the next sprint to get a better overview what is being worked on 14 | - Set sprint goals and check them into the team repository 15 | - Weekly management of the sprint goals via the org board in GitHub 16 | - Plan new sprint 17 | - tide 18 | - Carry over the “stable core” RFC into the next sprint ([link](https://github.com/rustasync/tide/issues/162)) 19 | - Session management 20 | - A way of handling CORS in tide 21 | - TLS 22 | - Authentication 23 | - runtime 24 | - Add WASI support (APIs + macros) 25 | - WASM Support (macros) 26 | - timers 27 | - UNIX domain sockets 28 | - Better stream syntax using `for_each` 29 | - async book 30 | - Outline done 31 | - Open issues for each section 32 | - Started the migration guide 33 | - Written two example sections 34 | - like how to write a future app (http client and server) 35 | - A crawler would be a good idea for a client. -------------------------------------------------------------------------------- /meetings/2019-05-16.md: -------------------------------------------------------------------------------- 1 | ## Six-Week Sprint (2019-05-16 — 2019-06-20) 2 | - [Open `"``sprint``"` issues](https://github.com/orgs/rustasync/projects/1) 3 | - Board is open now, ToDos are added for all open issues 4 | - How async-compression looks like right now will probably stay that way, aside from [asyncbufread](https://github.com/rustasync/async-compression/issues/21) 5 | - Writing a blog post about the [compression issue](https://github.com/rustasync/tide/issues/26) so people know there is a compression middleware available (will be added to the sprint goals) 6 | 7 | ## Working Group Updates 8 | - tide 9 | - `tide-cors`: We can re-use some implementation from actix, also @Prasanna L implemented a small version for tide which can be extended 10 | - The modular split for tide came quite far: One PR is merged, the other one can maybe be merged this week; we should land the last PR as well before we push a new release 11 | - `app.serve` will return a Future, where `app.run` starts the server (still some examples are needed for use cases and how it used in the end) 12 | - futures 13 | - Futures has a [new release(0.3.0-alpha.16)](https://github.com/rust-lang-nursery/futures-rs/releases/tag/0.3.0-alpha.16) which supports the new .await syntax 14 | - We need to open a discussion about moving Futures off the `-alpha`/`-preview` releases once it’s stabilizes 15 | - `Stream` is part of `futures-core` which is intended to be non-breaking once it releases 16 | - `Sink` is in a separate `futures-sink` crate, which means breaking changes are possible 17 | - runtime 18 | - no updates this week 19 | - books 20 | - Discussion around the outline/content started ([link](https://github.com/rustasync/book/issues/1)) 21 | - Open for input 22 | - No content yet 23 | - websites 24 | - No updates this week 25 | - PR sign off process 26 | - We need to establish basic, low key requirements to accept and merge pull requests 27 | - Maybe with the help of GitHub to set some requirements before a PR can be merged (minimum number of reviews for example) 28 | - PR has to be linked to an issue where consensus has been reached with regards to the general approach to solving the problem 29 | - The tool [bors](https://bors.tech/) might be a help with some of the issues 30 | -------------------------------------------------------------------------------- /meetings/2019-05-23.md: -------------------------------------------------------------------------------- 1 | 2 | # 2019/05/20 3 | - Reminder to write minutes 4 | 5 | ## Working Group Updates 6 | - RFC Triage 7 | - Two new RFCs will be opening discussion session management and authentication 8 | - Setting up a process for working with RFCs 9 | - Centralized RFCs repo or per repo RFC dir? 10 | - Per repo RFCs for now, more discussion to happen on the `rustasync/team` repo. 11 | - Six-Week Spring (2019-05-16 - 2019-06-20) 12 | - [Open “sprint” issues](https://github.com/orgs/rustasync/projects/1) 13 | - A lot of progress has been made across most of the issues being tracked. 14 | - Discussion around how to name extension traits in tide. More discussion to happen in the associated issue. 15 | - Status Updates 16 | - tide 17 | - Building a TodoMVC backend. 18 | - `tide-core`: more work has been done to decouple sub projects 19 | - RFCs will be opened soon for sessions and authentication. 20 | - futures 21 | - Biggest change is `futures-preview` now has a beta build which does not require the `async-await` feature. 22 | - runtime 23 | - Timers should be releasing next week. 24 | - Next month work will be starting on `for_await(parallel)` and a new crate `par` which abstracts over rayon/runtime 25 | - books 26 | - No progress made over the last week. 27 | - Meeting with the compiler team to have the right resources to guide people with the upcoming async/await feature. 28 | - websites 29 | - No updates this week. 30 | - Office hours 31 | -------------------------------------------------------------------------------- /meetings/2019-05-30.md: -------------------------------------------------------------------------------- 1 | 2 | 2019/05/30 3 | - Reminder to write minutes 4 | - Working Group Updates 5 | - RFC Triage 6 | - Have per repo RFC directories. 7 | - Six-Week Sprint (2019-05-16 — 2019-06-20) 8 | - Open [`sprint`](https://github.com/orgs/rustasync/projects/1) issues 9 | - General discussions around CORS middleware and authentication 10 | - Status updates 11 | - tide 12 | - https://github.com/rustasync/tide/pull/258 13 | - More discussion needed around whether or not we want to move `tide-router` into its own project. 14 | - For now the final core-split PR will merge the router back in 15 | - https://github.com/rustasync/tide/pull/262 16 | - armor http protection 17 | - Simple crate adding security headers 18 | - A possible way of using it with tide would be to add a separate crate with middleware providing integration. 19 | - paw support for structopt 20 | - Support being added for integrating with structopt, with the PR being almost ready. 21 | - futures 22 | - runtime 23 | - https://github.com/rustasync/futures-timer/pull/13 24 | - https://github.com/rustasync/runtime/issues/39 25 | - books 26 | - Minor updates around which topics and examples to include. 27 | - websites 28 | - Minor content updates and updating crates from time to time. 29 | - Policy for consistency in order to avoid back and forth switches between generics and impl syntax in arguments: https://github.com/rust-lang/rfcs/pull/2444 30 | - Link to updates ahead of time 31 | - Which crates can come under the umbrella of the WG? 32 | -------------------------------------------------------------------------------- /meetings/2019-06-13.md: -------------------------------------------------------------------------------- 1 | 2 | # 2019/06/13 3 | 4 | ## Working Group Updates 5 | - RFC Triage 6 | - One open RFC about extensible routing; needs more reviews ([link](https://github.com/rustasync/tide/pull/274/files)) 7 | - Six-Week Sprint (2019-05-16 — 2019-06-20) 8 | - [Open `"``sprint``"` issues](https://github.com/orgs/rustasync/projects/1) 9 | - Current status: 6 items done, 6 in progress, 7 in todo 10 | - Session Management has to be picked up by someone ([issue](https://github.com/rustasync/tide/issues/9#issuecomment-500628012)) 11 | 12 | ## Status updates 13 | - tide 14 | - Current master fails to build with nightly after about 2019-06-01 (bug in the compiler). This is affecting people who want to use tide obviously as well ([issue](https://github.com/rust-lang/rust/issues/61579)) 15 | - The restructure PR has to be merged so we can continue the other open todos ([pr](https://github.com/rustasync/tide/pull/258)) 16 | - testing framework is about to moved into its own submodule ([pr](https://github.com/rustasync/tide/pull/273)) 17 | - futures 18 | - No updates this week 19 | - runtime 20 | - No updates this week 21 | - books 22 | - No updates, “get book outline” is still open ([issue](https://github.com/rustasync/book/issues/1)) 23 | - The idea so far is moving it to a more cookbook style book 24 | - Weekly meetings to get the docs up to speed for async/await and 1.37; those will happen every Tuesday 25 | - CI is now in place to build the books 26 | - The book is being worked on this repository ([link](https://github.com/rust-lang/async-book)) 27 | - The book has its own zulip stream ([link](https://rust-lang.zulipchat.com/login/#narrow/stream/201246-wg-async-foundations.2Fbook)) 28 | - websites 29 | - No Updates this week 30 | - Pre-allocate agenda items 31 | - It would help the meeting in general to fill out the status updates before the meeting. The WASM WG is doing that and it seems to work quite well there. -------------------------------------------------------------------------------- /meetings/2019-06-20.md: -------------------------------------------------------------------------------- 1 | # 2019/06/20 2 | 3 | ## Working Group Updates 4 | ### RFC Triage 5 | - One open RFC about extensible routing; still needs more reviews - even just 'yay/nay'. ([link](https://github.com/rustasync/tide/pull/274/files)) 6 | ### Six-Week Sprint (2019-05-16 — 2019-06-20) 7 | - [Open "sprint" issues](https://github.com/orgs/rustasync/projects/1) 8 | - Current status: 8 items done, 6 in progress, 5 in todo 9 | - End of sprint - retro/planning session next week 10 | ## Status updates 11 | ### tide 12 | - A few new issues that need responding to ([#276](https://github.com/rustasync/tide/issues/276), [#280](https://github.com/rustasync/tide/issues/280), [#281](https://github.com/rustasync/tide/issues/281)) 13 | - Workaround PR for the nightly compiler issue ([#278]()) 14 | - Core Isolation PR [#258](https://github.com/rustasync/tide/pull/258)) needs final review 15 | ### futures 16 | - No updates this week 17 | ### runtime 18 | - merged the `time` PR [#36](https://github.com/rustasync/runtime/pull/36), released a new version 19 | - PR [#52](https://github.com/rustasync/runtime/pull/52) for `runtime::os::unix::net::UnixDatagram` 20 | ### books 21 | - playing with the new syntax and begun working through the examples in tokio to move them to the new syntax. 22 | - main goal right now is to get tokio moved by using those examples as a jumping off point. 23 | ### websites 24 | - No updates this week 25 | -------------------------------------------------------------------------------- /meetings/2019-06-27.md: -------------------------------------------------------------------------------- 1 | # 2019/06/27 2 | 3 | ## Working Group Updates 4 | ### RFC Triage 5 | - Only open RFC is around extensible routing in tide ([link](https://github.com/rustasync/tide/pull/274)) and will be worked on in this upcoming sprint 6 | ### Sprint planning 7 | - Main focus is `runtime` this sprint 8 | - Working on the book should be a priority as well with RustConf approaching and Futures + async/await being stable (soon) 9 | - @Nemo157 got a tide web app running on runtime-native ([link](https://github.com/rustasync/tide/issues/276#issuecomment-505193372)) and will add examples 10 | -------------------------------------------------------------------------------- /meetings/2019-07-04.md: -------------------------------------------------------------------------------- 1 | # 2019/07/04 2 | ## Working Group Updates 3 | - RFC Triage 4 | - One open RFC about extensible routing; needs more reviews ([link](https://github.com/rustasync/tide/pull/274/files)) 5 | - Six-Week Sprint (2019-06-27 — 2019-08-08) 6 | - [Open `"``sprint``"` issues](https://github.com/orgs/rustasync/projects/3) 7 | - Current status: 2 items done, 0 in progress, 9 in todo 8 | 9 | ## Status updates 10 | - tide 11 | - we should take a look at https://github.com/rustasync/tide/pull/274 12 | - futures 13 | - Futures is on stable! 14 | - runtime 15 | - https://github.com/rustasync/runtime/pull/64 by tirr, now landed 16 | - books 17 | - websites 18 | - Aaron stepping down from the WG 19 | - Bigbv has volunteered to step up 20 | - Yosh not around for the next two weeks 21 | - Bigbv will run the next meeting -------------------------------------------------------------------------------- /meetings/2019-07-11.md: -------------------------------------------------------------------------------- 1 | # 2019/07/11 2 | 3 | ## Working Group Updates 4 | ### RFC Triage 5 | - Nothing to report this week 6 | ### Six-Week Sprint (2019-06-27 — 2019-08-08) 7 | - [Open "sprint" issues](https://github.com/orgs/rustasync/projects/3) 8 | - Current status: 2 items done, 1 in progress, 9 in todo 9 | ## Status updates 10 | ### tide 11 | - Some PRs created this week: 12 | - tide-slog integration: PR [#287](https://github.com/rustasync/tide/pull/287) 13 | - tide/runtime example: PR [#283](https://github.com/rustasync/tide/pull/283) 14 | ### futures 15 | - No updates this week 16 | ### runtime 17 | - No updates this week 18 | ### books 19 | - effort going on to update the rust async book before the release of async/await 20 | ### websites 21 | - Looking to add new creates, e.g. embrio-executor 22 | - Looking to update web frameworks section of [http://www.arewewebyet.org/](http://www.arewewebyet.org) 23 | - Need to check activity level of some frameworks 24 | - ibaryshnikov will create a PR to get feedback from the community 25 | ### http-service 26 | - go take a look at the initial version of a lambda integration 27 | 28 | ## General discussion 29 | - Should we change the format to leave RFC Triage for new RFCs and integrate RFC updates 30 | within the status updates? Will have more discussion at a later date about this. 31 | -------------------------------------------------------------------------------- /meetings/2019-07-18.md: -------------------------------------------------------------------------------- 1 | # 2019/07/18 2 | 3 | ## Working Group Updates 4 | ### RFC Triage 5 | - Nothing to report on this week 6 | 7 | ### Six-Week Sprint (2019-06-27 — 2019-08-08) 8 | - [Open "sprint" issues](https://github.com/orgs/rustasync/projects/3) 9 | - Current status: 2 items done, 1 in progress, 9 in todo 10 | 11 | ### Status updates 12 | - tide 13 | - RFC for extensible routing is still under discussion (“should it be extensible or not?”) ([link](https://github.com/rustasync/tide/pull/274)) 14 | - Triage meeting is planned for the upcoming Monday to gain momentum again in tide and go through stalled issues, (re)label and assign them 15 | - We have to push a new release because of the `async_closure` chages. Tide is currently not usable with nightly ([link](https://github.com/rustasync/tide/issues/290)) 16 | - futures 17 | - Rust 1.36 stabilized the Future trait ([link](https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html)) 18 | - runtime 19 | - no updates this week 20 | - books 21 | - The language team is working on the documentation around async/await 22 | - Meetings on the async book are held in zulip (so far not much progress in the last couple of weeks) 23 | - websites 24 | - arewewebyet: PR open with updated information ([link](https://github.com/rustasync/arewewebyet/pull/199)) 25 | - aerwewebyet: Update on the recommended frameworks, removed outdated information ([link](https://github.com/rustasync/arewewebyet/pull/198)) 26 | - http-service 27 | - Rust version upgraded, repaired CI status ([PR](https://github.com/rustasync/http-service/pull/39)) 28 | - Implement an example http-service which runs on AWS Lambda ([PR](https://github.com/rustasync/http-service/pull/37)) -------------------------------------------------------------------------------- /rfcs/0000-template.md: -------------------------------------------------------------------------------- 1 | - Feature Name: (fill me in with a unique ident, `my_awesome_feature`) 2 | - Start Date: (fill me in with today's date, YYYY-MM-DD) 3 | - RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000) 4 | - RustAsync Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000) 5 | 6 | # Summary 7 | [summary]: #summary 8 | 9 | One paragraph explanation of the feature. 10 | 11 | # Motivation 12 | [motivation]: #motivation 13 | 14 | Why are we doing this? What use cases does it support? What is the expected outcome? 15 | 16 | # Guide-level explanation 17 | [guide-level-explanation]: #guide-level-explanation 18 | 19 | Explain the proposal as if it was already included in the language and you were teaching it to another Rust programmer. That generally means: 20 | 21 | - Introducing new named concepts. 22 | - Explaining the feature largely in terms of examples. 23 | - Explaining how Rust programmers should *think* about the feature, and how it should impact the way they use Rust. It should explain the impact as concretely as possible. 24 | - If applicable, provide sample error messages, deprecation warnings, or migration guidance. 25 | - If applicable, describe the differences between teaching this to existing Rust programmers and new Rust programmers. 26 | 27 | For implementation-oriented RFCs (e.g. for compiler internals), this section should focus on how compiler contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms. 28 | 29 | # Reference-level explanation 30 | [reference-level-explanation]: #reference-level-explanation 31 | 32 | This is the technical portion of the RFC. Explain the design in sufficient detail that: 33 | 34 | - Its interaction with other features is clear. 35 | - It is reasonably clear how the feature would be implemented. 36 | - Corner cases are dissected by example. 37 | 38 | The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. 39 | 40 | # Drawbacks 41 | [drawbacks]: #drawbacks 42 | 43 | Why should we *not* do this? 44 | 45 | # Rationale and alternatives 46 | [rationale-and-alternatives]: #rationale-and-alternatives 47 | 48 | - Why is this design the best in the space of possible designs? 49 | - What other designs have been considered and what is the rationale for not choosing them? 50 | - What is the impact of not doing this? 51 | 52 | # Prior art 53 | [prior-art]: #prior-art 54 | 55 | Discuss prior art, both the good and the bad, in relation to this proposal. 56 | A few examples of what this can include are: 57 | 58 | - For language, library, cargo, tools, and compiler proposals: Does this feature exist in other programming languages and what experience have their community had? 59 | - For community proposals: Is this done by some other community and what were their experiences with it? 60 | - For other teams: What lessons can we learn from what other communities have done here? 61 | - Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. 62 | 63 | This section is intended to encourage you as an author to think about the lessons from other languages, provide readers of your RFC with a fuller picture. 64 | If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages. 65 | 66 | Note that while precedent set by other languages is some motivation, it does not on its own motivate an RFC. 67 | Please also take into consideration that rust sometimes intentionally diverges from common language features. 68 | 69 | # Unresolved questions 70 | [unresolved-questions]: #unresolved-questions 71 | 72 | - What parts of the design do you expect to resolve through the RFC process before this gets merged? 73 | - What parts of the design do you expect to resolve through the implementation of this feature before stabilization? 74 | - What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? 75 | 76 | # Future possibilities 77 | [future-possibilities]: #future-possibilities 78 | 79 | Think about what the natural extension and evolution of your proposal would 80 | be and how it would affect the language and project as a whole in a holistic 81 | way. Try to use this section as a tool to more fully consider all possible 82 | interactions with the project and language in your proposal. 83 | Also consider how the this all fits into the roadmap for the project 84 | and of the relevant sub-team. 85 | 86 | This is also a good place to "dump ideas", if they are out of scope for the 87 | RFC you are writing but otherwise related. 88 | 89 | If you have tried and cannot think of any future possibilities, 90 | you may simply state that you cannot think of anything. 91 | 92 | Note that having something written down in the future-possibilities section 93 | is not a reason to accept the current or a future RFC; such notes should be 94 | in the section on motivation or rationale in this or subsequent RFCs. 95 | The section merely provides additional information. 96 | -------------------------------------------------------------------------------- /rfcs/0001-sprint-1.md: -------------------------------------------------------------------------------- 1 | - Feature Name: N/A 2 | - Start Date: (fill me in with today's date, 2019-03-27) 3 | - RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000) 4 | - RustAsync Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000) 5 | 6 | # Summary 7 | [summary]: #summary 8 | 9 | The roadmap for the first 6 week for the Rustasync ecosystem work group. 10 | 11 | This RFC is intended to provide the general outline and define the goals for the first sprint. The 6 week sprint provides a block time long enough to take a feature to completion, while at the same time being short enough that things do not stagnate. 12 | 13 | Since this will be the first sprint for the async ecosystems wg, the goal is to build a good foundation on which future work can proceed. 14 | 15 | * Start date: *28 March* 16 | * End date: *2 May* 17 | 18 | # Detailed description 19 | [detailed-description]: #detailed-description 20 | 21 | # Tide 22 | [tide]: #tide 23 | 24 | The project has seen a lot of discussion happen in [issues][issues] as well as the discord channel. The general conversation currently revolves around getting the core framework stabilized in order to build features on top of that. To this end, the currently [open PR by @aturon][context-pr] works to refactor the way data is passed along to endpoint functions. This change is a major change allowing data extraction to be more explicit. 25 | 26 | Once this feature lands, here are some of the issues that work can begin on: 27 | 28 | * [Authentication in Tide][issues-99] 29 | * [Serving static files][issues-63] 30 | * [URL generation][issues-24] 31 | 32 | There has been some discussion on the [Sprint 1 goals issue][sprint-goals], and a really good overview for the features to work on has been been [outlined by @gruberb][goals-outline]. This outline a great basis to set up the roadmap for Tide. It consists of the following broad goals: 33 | 34 | * [ ] Stabilize tide core. 35 | * [ ] Session management 36 | * [ ] Authentication 37 | 38 | ## Merge Context PR 39 | [merge-context-pr]: #merge-context-pr 40 | 41 | Currently [the PR][context-pr] is open, with most of the core changes done. There is ongoing discussion regarding the change, and you can follow with the progress directly on the PR. 42 | 43 | 44 | ### Goals 45 | [stabilize-core-goals]: #stabilize-core-goals 46 | 47 | * [ ] Merge PR 48 | * [ ] Resolve design questions. 49 | 50 | ## Session management 51 | [session-management]: #session-management 52 | 53 | Current discussion around session management in tide is centered around the [design issue][issues-9] for the same. @tomhoule has got a working generic session implementation written against the new tide core changes. You can check the [project out here][session-project]. This provides types to define middleware and custom session storage backends which hook directly into the `Context` object provided to the endpoint function. 54 | 55 | The current discussion is centered on providing a simple in memory session storage with Cookies as the default in the framework, and provide external crates to hook into external data stores. 56 | 57 | This change is currently blocked by the tide core changes. 58 | 59 | ### Goals 60 | 61 | * [ ] Stable API. 62 | * [ ] In memory session backend 63 | 64 | ## Authentication 65 | [Authentication]: #authentication 66 | 67 | Currently rust web frameworks have disparate ways of authentication. One of the goals of the Async ecosystem WG is to provide a common set of crates which can be used to build higher level abstractions. In terms of Tide, there currently isn't an authentication story present. @tomhoule has built cookie based authentication into the session management middleware as a POC. Therefore the goals for this sprint would be to sketch out the design of the authentication API for tide. 68 | 69 | ### Goals 70 | 71 | * [ ] Design authentication API in Tide. 72 | 73 | [issues]: https://github.com/rustasync/tide/issues/ 74 | [context-pr]: https://github.com/rustasync/tide/pull/156 75 | [issues-9]: https://github.com/rustasync/tide/issues/9 76 | [issues-99]: https://github.com/rustasync/tide/issues/99 77 | [issues-63]: https://github.com/rustasync/tide/issues/63 78 | [issues-24]: https://github.com/rustasync/tide/issues/24 79 | 80 | [sprint-goals]: https://github.com/rustasync/team/issues/96 81 | [goals-outline]: https://github.com/rustasync/team/issues/96#issuecomment-471552499 82 | [session-project]: https://github.com/tomhoule/tide-cookie-session 83 | 84 | # Websites 85 | [websites]: #websites 86 | 87 | There are two primary websites for keeping tack of async await progress and web development progress: 88 | 89 | * [Areweasyncyet][areweasyncyet] 90 | * [Arewewebyet][Arewewebyet] 91 | 92 | There isn't a lot that has been discussed around these two as they are in maintenance mode and work will mostly be around updating the content as and when appropriate. 93 | 94 | [areweasyncyet]: https://areweasyncyet.rs/ 95 | [arewewebyet]: http://www.arewewebyet.org/ 96 | 97 | # Async book 98 | [async-book]: #async-book 99 | 100 | The current [Async book][async-book] is a great start at explaining the details of why `async/await` is important, but is light on the details. As mentioned in [this issue][lucio-issue], there are discussions on improving the contents and providing a starting point for people wanting to learn about how the feature works. There are also plans for adding sections for helping maintainers of existing libraries to migrate to std futures. 101 | 102 | The book can also provide guides for building different kinds of software using `async/await` as well as provide guides for people wanting to help out with the documentation and migration effort, akin to [Tokio's doc-push][doc-push]. 103 | 104 | 105 | ### Goals 106 | 107 | Echoing the theme of the sprint, the goals for the book will be to provide a good foundation to build upon. 108 | 109 | Some general goals are 110 | 111 | * [ ] Outline chapters 112 | * [ ] Move Async book to rustasync org 113 | * [ ] Provide guides for writing chapters. 114 | 115 | # Library ecosystem 116 | [library-ecosystem]: #library-ecosystem 117 | 118 | There are a lot of existing libraries which use Future 0.1 . As it stands there is no resource to refer to when a library maintainer would want to port their library to work with std futures. [The issue][lucio-issue] mentioned in the previous section goes into more detail, but the general theme is to provide material and help for library maintainers to migrate their libraries to std Futures. 119 | 120 | ### Goals 121 | 122 | Some general goals for this sprint are: 123 | 124 | * [ ] Reach out to crate maintainers and learn their requirements 125 | * [ ] Migrate projects for experience reports. 126 | 127 | 128 | [async-book]: https://rust-lang.github.io/async-book/ 129 | [lucio-issue]: https://github.com/rustasync/team/issues/102 130 | [doc-push]: https://tokio.rs/blog/2018-10-doc-blitz/ 131 | --------------------------------------------------------------------------------