Advertisement
Guest User

Untitled

a guest
Mar 18th, 2019
54
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 6.58 KB | None | 0 0
  1. Vision of the WG(@aturon):
  2. https://rust-lang-nursery.github.io/wg-net/web-foundations/
  3. There are a lot of crates for working with web, but no one has looked at the big-picture.
  4. Eg: Making sure various crates fit well, standardized interfaces, locating missing features.
  5. 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.
  6. Compounded by async-rust flux.
  7. Goal: Improve state of affairs, while being very open and collaborative.
  8. Vision document: focused on what's feasable for the rest of the year
  9. Two related efforts: "Top down", "Bottom up"
  10. Top Down:
  11. Building a web framework (Tide) based almost entirely on external crates
  12. A way to drive overall work, set up clear needs and have a useful artifact at the end.
  13. Strive to build all new functionality in re-usable crates which are not specific to the framework
  14. Use this as a way to standardize on interface and make specific recommendations on what crates to use, etc.
  15. Plan on writing this as a small book in addition to the framework itself.
  16. This will go through each aspect of web development and explain the ecosystem around it.
  17. Bottom up:
  18. Discovering and trying to use existing crates, and writing small experiments and examples
  19. Driven in part by surveys and community-provided examples and requests.
  20. These two should come together at some point, but currently are separate efforts
  21. By the end of 2019,there should be significantly more documentation and guidance around rust-web.
  22. A lot of improvements should have been made in the crates used in the ecosystem.
  23. Have a new framework built.
  24. Questions:
  25. How to avoid confusion with adding a new framework?
  26. Tower is for a general abstraction for services.
  27. Idea is to use Tower to build Tide
  28. Make a distinction between providing a service vs a full fledged framework.
  29. Want to contribute to crates like tower-service, hyper, http, url etc.
  30. Rocket, Gotham, warp, tower-web are existing frameworks and Tide will be adding to the list.
  31. Hopefully, by doing this in a component-driven way, we can help all those frameworks share more code.
  32. (@rolf) looks like we are looking for some core abstraction(s) to settle on.
  33. Status of Tide/How to participate(@aturon):
  34. Fundamental parts of a framework need to be built (Before external crates can be used).
  35. A start on a blog series:
  36. (+Rising Tide: building a modular web framework in the open )
  37. Trying to outline the goals of a web framework in general.
  38. Take a look at those fundamental pieces.
  39. First two: The service abstraction and routing:
  40. Service abstraction:
  41. Service abstraction is what @rolf was alluding to.
  42. What rack provides in the ruby world.
  43. A general way of saying: "A function that consumes requests and produces responses."
  44. Can be pretty subtle.
  45. Goal: Decouple web app/frameworks from web servers.
  46. Most frameworks in rust use hyper directly.
  47. actix is the exception which uses its own server.
  48. With the service abstraction, a "many-to-many" relationship possible between servers which consume underlying protocol and frameworks which can help you write services.
  49. Different from the Service trait in hyper.
  50. Should ideally exist in a standalone crate
  51. @seanmonstar: effort already exists:
  52. generalizing hyper into the http crate and tower-service to be the rack/wsgi/servlet of rust.
  53. @aturon: get the WG more involved and get community buy-in on standardizing.
  54. Once this abstraction exists, a framework is a fancy way of writing services.
  55. Helps factor out HTTP and other concerns.
  56. Routing:
  57. Note: some frameworks like warp don't need routing as a separate concern.
  58. Many possible approaches.
  59. @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.
  60. Routing is opinionated. At the same time there are already a couple of clear "styles".
  61. The implementation can be standardized.
  62. (@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.:
  63. First steps: a bunch of digging and will be writing thoughts.
  64. Hoping that after the first couple of posts, to get more people involved.
  65. Will be opening issues for some of these questions.
  66. Will be looking for collaborators.
  67. For now, just let me know if you're interested.
  68. (@Carl Lerche): pushing on BufStream to standardize the body:
  69. Combo of Service, http Request/Response/BufStream is going to be tower-http
  70. BufStream is moving to tokio-buf
  71. Once this work is done, work will start at integrating tower and these traits in hyper and warp
  72. tower-web also includes a middleware trait to push on those concepts.
  73. Working with actix
  74. If warp + actix move to Tower that makes the ecosystem.
  75. (@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.
  76. (@aturon): Hope to use the WG to drive help from the community for these topics.
  77. Micro projects(@yoshyawuyts):
  78. Tracking issue for the bottom up work:
  79. https://github.com/rust-lang-nursery/wg-net/issues/45 :
  80. Come up and implement small projects in order to improve the status quo around web rust.
  81. Activity has slowed down somewhat recently.
  82. Not sure if the idea behind it was explained well.
  83. Can the wg-net blog draw more attention to the effort?
  84. Can quest issues help?
  85. Crowd sourcing the kinds of examples people would like to see in the web space.
  86. Idea for a blog post: explain the effort nd ask for both crowdsourcing of examples and for participation in implementing them.
  87. Survey (@yoshyawuyts):
  88. It'd be great to have a survey to ask people how folks are using rust for web programming.
  89. Not sure where to start.
  90. @rolf: how many people can be reached by the survey?
  91. @aturon: the rust survey hits 5k people every year. CLI WG survey got at least several hundred.
  92. @rolf: making easy to fill with checkboxes and radio buttons instead of free form answers will help gather a lot of information.:
  93. What are the pain points?
  94. Figure out people's experiences.
  95. What modules they use, what they think is good, what they think is less good.
  96. Open a new issue for a general web survey.
  97. Blog posts (@yoshyawuyts):
  98. We have some posts in works.
  99. Do these posts go on the web-net website or personal websites?
  100. WG website.
  101. Talk to framework authors about their frameworks.
  102. Create tracking issue:
  103. Discuss good questions and get authors involved.
  104. Newsletter(@yoshyawuyts):
  105. Date for shared newsletter confirmed: 12 September.
  106. Posting to internals.rust-lang.org
  107. Tracking issue: https://github.com/rust-lang-nursery/wg-net/issues/51
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement