Agenda
- Work through https://github.com/rust-lang-nursery/wg-net/issues/24 and https://github.com/rust-lang-nursery/wg-net/issues/35
- Please read these threads and leave comments in advance of the meeting
- Goal: arrive at rough consensus for the preliminary vision and structure of the WG
- I expect this to take most of our meeting time!
- Notes
- End goal: Have a high level vision for structuring the WG.
- Arrive at a rough consensus at the end of the meeting
- 2018 vision
- What is the scope of the changes? Language or Ecosystem
- Depends on the end results.
- Async foundations involve language change
- Language changes not scheduled for 2018 shouldn’t be considered.
- What is the scope of the changes? Language or Ecosystem
- Deployment story valid for this WG?
- Question of resource prioritization
- How much work would be accepted to get things like OpenSSL and musl on the official docker image.
- Ring is a problem
- A branch started in December is close to allowing multiple versions to be linked? https://github.com/briansmith/ring/pull/619
- Big companies generally have their own internal base images to build off of.
- Maybe have docs on how to set it up with an example image.
- Getting rust to build in a reproducible, secure manner across OSes
- Important to not just wg-net
- Strawman proposal: https://github.com/rust-lang-nursery/wg-net/issues/24#issuecomment-409081766
- Not included in the strawman:
- Ecosystem foundations don’t talk about integrating the existing ecosystem with async rust
- Web foundations is good, but we need a high level story for other use cases
- Not included in the strawman:
- Some issues regarding the web context:
- There’s a lot in terms of the web context, but it doesn’t work together.
- Unclear decision making interms of low and high level abstractions.
- Too much concern into the request response paradigms, which ignores other use cases
- “Web foundations” is intended to focus n the coherence/compat of the web ecosystem.
- Not sure of the vision for web in rust in general. What does it entail? Components? Web frameworks?
- There is disconnect between tokio and threads.
- No coherent story for managing contexts in a generic way.
- think go contexts, .net execution contexts, jai's implicit context etc.
- Contexts should work in both async and sync rust code.
- Some form of example guide for getting started with async IoT in rust with good patterns highlighted.
- Ecosystem survey:
- what’s the approximate scope?
- If multiple crates cover the same functionality, how should that be handled.
- 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
- Web is an important story to get right
- Having a clear “End to End” goal is important.
- Focus on documentation.
- Start building the website (which website)
- and writing docs for different use cases.
- The holes in the ecosystem will show up when doing this.
- Have reasonably clear “final deliverables”
- websocket support would be a way to address non request-response oriented protocols.
- Guides as deliverables
- How to reconcile this with not having official defacto libraries.
- Should we avoid “picking a winner” by making an official recommendation?
- Proposed change to the vision:
- Async foundations
- IoT/embedded foundations (Focus on networking and not embedded in general)
- Web foundations
- Ecosystem pillar can be an open-ended/undirected ecosystem-focused driven by two particular domains of use.
- Lots of opportunity in the data plane, how should that be addressed?
- Documentation for different audiences.
- Quick getting started style guides
- In-depth understanding of foundational components.
- 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
- Finish building and shipping async seems like a separate effort
- A good overview for async deliverables can be gleaned from the contents of https://aturon.github.io/apr/
- Everything doesn’t need to be end-to-end, but should have a proper deliverable.
- WG has low level usecases and high level usecases and each is being represented by a concrete example.
- Strawman proposal for the organizational structure of the WG
- Have two “point people” for each pillar.
- They will lead/coordinate
- Have two for availability and have different opinions.
- WG members will gravitate towards one of these main areas of work.
- Each sub group can work out its own way of setting a more detailed granular vision.
- Leads will have a regular meeting to help coordinate the different efforts.
- This is a repetition of the team structure followed in the Rust project.
- Have two “point people” for each pillar.
- Leads should be picked by interest and availability.
- Proposed leads:
- async foundations: cramertj + MajorBreakfast
- Formalizing what is already in place.
- Embedded foundations: Nemo157 + Ikurusa
- Web foundations: aturon + yoshuawuyts
- Once the leads are settled, a signup sheet for individual pillars will be available.
- Should debug/introspection/tooling be it’s own pillar?
- Should probably flow from the different useases/pillars
- Very important
- How much time is required of the lead?
- Depends on how much help is coming from the sub group itself.
- leads can also rotate over time.
- There might be an abundance of interest in web, but embedded might be an issue.
- What happens next:
- aturon follows up with the leads to help firm up logistics.
- He will send an email + a note on how to sign up for sub groups.
- Fine to do multiple, shift overtime/etc.
- Basically a mailing list to make sure the sub group can organize things.
- 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.
- Most likely that the leads will have regular meetings open for anyone to join in.
- The sub groups should be largely independent in organization but with regular cross-cutting check-ins.
- End goal: Have a high level vision for structuring the WG.