As a follow-up to https://github.com/http-rs/tide/issues/325, I'd like to share the plan of how we can get Tide to a publishable state. This is not so much an issue to ask for input, but more to share what the plan is in case people are confused by what's going on.
The core problem I think we currently have is one of my design: we have too many different crates, which makes it hard to publish & manage. In contrast: async-std has all functionality as part of a single repo, and adds new features behind the "unstable" feature flag. I think we __should consolidate Tide into a single crate, and introduce an "unstable" feature flag__.
I think we should very much do the same, and the easiest way to get there is by resetting the repo by a few dozen commits to 4a538908f928aa1108473d1832073fc5cb799cc6, the commit right before all the "split" PRs landed.
_Note that this was fantastic work, implemented by @prasannavl. But I think this wasn't the right direction, which is entirely on me._
From there we can move back through the commit log and start applying patches that have landed before. I estimate this to be a few uninterrupted days worth of work.
From there the plan is less clear. But I have some idea of API changes I'd like to make. But before we do that we should probably create a new "snapshot" release so people can work off the latest master branch.
I'd like to spend some effort during all this to write docs. We don't really have much right now, and I think that's holding us back. Unsure about the exact timeline, but it's something I think needs to be prioritized.
This all sounds cool, how can I help?
Unfortunately I think there's not much that can be done right now. The only separate issue that's coming up is https://github.com/http-rs/http-service/issues/31; so if you want to pick this up and help port http-service that would be fantastic. Please note though that I won't have any bandwidth to mentor this, and it won't be easy.
Other than that this is mostly me effectively taking a lock on the project to move things forward. Once that's over I should have a better idea of which steps to take after, and tracking issues can be written. That's all further out still though. More updates in the future!
Conclusion
This is the current work plan I'm thinking of executing on. This means some big changes, but the path seems clear.
yoshuawuyts
All 17 comments
A permanent archived branch of the current HEAD of Tide can be found here: https://github.com/http-rs/tide/tree/archive-split
yoshuawuyts
on 30 Oct 2019
I would also like to see Tide enter a usable state, which is the driving force behind several of the commits I've tried to land over the past week. Most of the work has been in small chunks, but almost all of the PRs addressed needs that were long in the tooth and needed to be resolved.
I also completely support most of the ideas above, except recombining Tide into a single crate. As I understand it, async-std is an attempt to re-implement the Rust standard library, using async-first principals rather than assuming the environment supports a threaded execution model. From a "standard library" approach, where you're providing a bucket of code that is relevant to most programs, I completely agree that introducing new features behind and unstable flag makes sense. I also think Tide is a different environment, and it's relatively easy include "standard" features as defaults within the main tide crate. I also don't like the idea of rewinding repo history.
Honestly, rewinding repo history and reorganizing the crate structure seems like the opposite of getting Tide ready to go.
I have several commits that are ready to push up, including some work on the middleware stack, related to the PR for nested routes that I merged a few days ago. I'd strongly prefer not to reorganize the project once again.
Edit: I just noticed Tide's master branch has been reverted without contributor input. When this issue was posted, I feared that Tide was becoming a personal project with less input from contributors. I was entirely correct, and I don't enjoy being right this time.
secretfader
on 30 Oct 2019
Other than that this is mostly me effectively taking a lock on the project to move things forward. Once that's over I should have a better idea of which steps to take after, and tracking issues can be written. That's all further out still though. More updates in the future!
^ Why Tide is broken, in a nutshell. A maintainer who has done little work in the past few months returns to save the project!
secretfader
on 30 Oct 2019
@secretfader Let me be clear: I've tried my best to communicate all of this in the past. Tide has been stagnant for the last 6 months, and has been at a directional impasse since Aaron's departure from the project.
You dropped off for several months without notice, ignored all of my DMs, stopped attending WG meetings, and apparently didn't bother to read meeting notes either. To come in telling me "this is now a personal project" is quite something.
In order for a project to succeed, the people working on it need to communicate. You haven't made me aware of any plans you had, and apparently were working off of assumptions. The fact that you've decided to do work in the last week doesn't change this.
To be honest I'm really not in the mood to have to deal with this right now. We have major events right around the corner, and after 6 months of little movement now is the time to move forward.
I'd like to end this reply with emphasizing that at no point was this issue intended as an invitation for dialogue. The sole intent was to communicate direction. Given this project is no longer governed by any official Rust organization, I'd like to state that I do feel comfortable enforcing boundaries. And I'd very much like to not drag discussion about this any further. Thanks for your understanding.
yoshuawuyts
on 30 Oct 2019
A maintainer who has done little work in the past few months returns to save the project!
Yep, nope. That's quite enough. I don't have time to deal with whatever you think you hope to achieve here. Goodbye.
yoshuawuyts
on 30 Oct 2019
Now that 0.3.0 has been released, the work begins to rewind prior patches onto the current master in order to release 0.4.0. In order we should do the following patches.
_Sourced from the PR page_:
Page 3
- [x] #221 Fix example link in readme.
- [x] #222 Add Tide log.
- [x] #231 Remove #[allow(unused_mut)]
- [x] #233 Improve curl command consistency
- [x] #239 Rename trait ExtractForms to ContextExt
- [x] #241 Adjust code quality encorcement
- [x] #242 Fix broken links in readme
- [x] #245 remove async box macro
- [x] #246 Sweep the cache before uploading it
- [x] #250 Add doc comment
- [x] #253 pub use ResultDynErrExt in tide::error
Page 2
- [x] #254 Fix the documentation for wildcards for path definitions
- [x] #256 Fix links in readme
- [x] #260 rename Context to Context
- [x] #194 Compression middleware
- [x] #261 Propagate Hyper error on serve failure
- [x] #262 Implemented CORS header handler middleware
- [x] #265 Add middleware for catching panics
- [x] #267 Add templating example with tera
- [x] #272 Adjust docs for consistency
- [x] #275 Cors middleware extension
- [x] #283 Tide on Runtime
- [x] #285 Set statuscode for an empty response from () to 204
- [x] #287 Update tide-slog
- [x] #291 Add doc example showing query param extraction
Page 1
- [x] #299 Replace serde_urlencoded with serde_qs
- [x] #301 Remove existential_type feature
- [x] #303 Fix clippy error in static file exmaple
- [x] #317 Cookies: is &mut required?
- [x] #318 CORS Middleware: better handling of Origin
- [x] #331 Nested router example
- [x] #332 if JSON serialize failure return 500 and error message
- [x] #334 Remove dev dependency on Runtime crate
yoshuawuyts
on 31 Oct 2019
I'm very cautious of any projects that do hard resets. (Infact, would go so much to say that I'd never ever do that in public projects with other contributors unless there's a serious security issue).
This simply dismissed every contributor's work from the point of the reset (they will no longer be accredited for their work). Note that I do not have problems with the decision to rewind as such, even though I wish this was experimented/discussed more transparently and for slightly longer time - however, speaking for myself, I was busy and barely involved with WG for over 2 months, and as such I have no problems with decisions being made without being expected to be kept in the loop, but I think the way in which they were made and executed here raises questions.
If it had to be done, this IMO should have been done with reverts that don't make the contributions of others disappear into thin air. Instead, what happened here, I think goes against the nature of good open source software conduct. Erasing the work of others who had invested time and code into the project due to it's nature of association to the WG, just because it no longer is, makes me very uneasy.
prasannavl
on 1 Nov 2019
@prasannavl I hear you, and don't disagree. However I don't quite have the ability to use git in such a way that I know how to replay commits done on separate files on top of a different file tree. It might be possible, but it'd definitely take a while.
I feel the biggest loss of work is probably yours though, as you're the person that executed the project split. I'm deeply appreciative for the work you've done, and think you did it well. However the design left us in a state where it was hard to publish, and as such it became apparent after the fact that we had to change course again.
What I've done here is to try and get us to a publishable state, within the best of my ability. I wanted this to be in a timescale of days, not weeks or months as I estimated approaches would take. I understand this may not be entirely satisfactory, but I hope you can empathize with the desire for Tide to remain an active project and keep moving ahead.
yoshuawuyts
on 1 Nov 2019
In case this is only about lack of git foo, I pushed https://github.com/dtolnay/tide/commit/1b67aa43879a728854d31dfae3a451cfae31abb5 which has contents that are identical to current master but doesn't discard any of the project history.
dtolnay
on 1 Nov 2019
@dtolnay thank you for providing the neat solution! that if rebased upon, pretty much addresses my concern.
@yoshuawuyts - personally, I'd feel much more comfortable rebasing on top of that above whenever you get the time. I wrote my previous comment at the risk of being excessively nitpicky there, but for a healthy open collaboration, I quite strongly believe erasing history should be avoided as a matter of principle.
On the changes itself and my work on the split being the most to go - honestly, I couldn't care less about it - things being changed and the discovery of the sweet spot is a part of the lifecycle of pre v1.0 projects and have no objections to any of it whatsoever. While I evidently had a different direction in my mind, I also wasn't able to put the time into it to follow them up with larger contributions.
I personally see single crate, or multiple crates to be minor issues in the grand scheme of things, compared to practical functionality and progress of the project especially when it has stagnated. It's a lot of work either way, and if you think all this reversal will help bring more progress, I'm just glad that you've decided to take this head on and move this forward in whichever way you see as the best fit accordingly. And thank you for putting in your time to get it moving!
prasannavl
on 1 Nov 2019
All commits have been rewound. Waiting on CI to pass before merging the third batch, and then we should be good.
Going to pick this back up next week. Probably first step is to do a general pass and do some spring cleaning. The current state of docs isn't great, and some reorganization would go a long way. Once that's done we should probably do a snapshot release again.
The step after that is to do a step-by-step review of each API, and mark everything outside of Tide core as "unstable". We then have some freedom to edit APIs, and slowly stabilize them.
Somewhere along this process we should also address https://github.com/http-rs/http-service/issues/31, but I'm not sure when the right time is. Either way, the first few steps seem clear.
Thanks for your patience y'all!
yoshuawuyts
on 3 Nov 2019
Thanks for your hard work on this. I really appreciate your transparency and I like the choices you've made regarding the developer/user centric focus on the API.
Is this the correct place to discuss an HTTP2 strategy? Apologies if it is not.
Adoption of HTTP2 is quite pervasive now, and there are performance and usability advantages to be had. Stats show that almost 50% of websites support it, and I think all browsers and most CLI clients support it.
I am not demanding that we incorporate it immediately, but it would be good to get a high level architectural picture about how I, as a developer, could hope to have a single set of tools to manage http/2 upgrade/fallback and ALPN, and be able to have my routes/handlers serve requests without regard for the underlying protocol.
rrichardson
on 29 Nov 2019
@rrichardson o/ thanks for raising! We definitely want to support HTTP/2, but I'd like us to be deliberate about it and ensure the foundation is in place for us to add it. This includes TLS, WebSockets, and error handling first.
If we were to add it I'd probably want to us to have the ability to use nghttp2 for this. I started initial work on creating high-level bindings to it in https://github.com/http-rs/nghttp2; but that work needs to be finished. If you're interested in progressing this, help would be very welcome!
yoshuawuyts
on 13 Dec 2019
@yoshuawuyts Why put effort into bindings for C-based code rather than using Rust exclusively?
kellytk
on 13 Dec 2019
@kellytk nghttp2 is the most widely deployed HTTP/2 implementation used by Curl, Node.js, and Nginx alike. Being able to rely on the same impl would be quite nice.
Though perhaps you're right; the argument for having nghttp2 bindings was stronger at the start of the year, as Rust alternatives didn't implement the full spec. It seems they have caught up; at least now it's closer to what we could use. The only downside is that impls such as h2 advertise they depend on tokio, which is a non-starter for us as we'd like to use implementations that are built on futures / runtime agnostic. Maybe this is worth digging in deeper for though.
yoshuawuyts
on 17 Dec 2019
I feel most points in this issue have already been addressed. I reckon we'd be better off migrating to smaller-grained issues from this point forward. Going to go ahead and close this, and then do some issue maintenance later this week. Thanks all!
yoshuawuyts
on 17 Dec 2019
Is there any update on HTTP/2 support? I couldn't fine a tracking issue for it...
ibraheemdev
on 24 Jan 2021
Related issues
aturon
路
6Comments
milesgranger
路
6Comments
yoshuawuyts
路
6Comments
lichr
路
4Comments
Nemo157
路
6Comments
Most helpful comment
Now that 0.3.0 has been released, the work begins to rewind prior patches onto the current master in order to release 0.4.0. In order we should do the following patches.
_Sourced from the PR page_:
Page 3
Page 2
Page 1