Tide development plan

[yoshuawuyts]

As a follow-up to #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 4a53890, 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 http-rs/http-service#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]

A permanent archived branch of the current HEAD of Tide can be found here: https://github.com/http-rs/tide/tree/archive-split

[secretfader]

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]

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!

[yoshuawuyts]

@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]

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]

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

• Fix example link in readme #221 Fix example link in readme.
• add tide-log #222 Add Tide log.
• Remove #[allow(unused_mut)] #231 Remove #[allow(unused_mut)]
• Improve curl command consistency #233 Improve curl command consistency
• Rename trait ExtractForms to ContextExt #239 Rename trait ExtractForms to ContextExt
• Adjust code quality enforcement #241 Adjust code quality encorcement
• Fix broken links in readme #242 Fix broken links in readme
• remove async box macro #245 remove async box macro
• Sweep the cache before uploading it #246 Sweep the cache before uploading it
• Add doc comment #250 Add doc comment
• pub use ResultDynErrExt in tide::error #253 pub use ResultDynErrExt in tide::error

Page 2

• Fix the documentation for wildcards for path definitions to match implementation #254 Fix the documentation for wildcards for path definitions
• Fix links in README #256 Fix links in readme
• Rename Context<Data> to Context<State> #260 rename Context to Context
• Middleware-based compression and decompression #194 Compression middleware
• Propagate hyper error on serve failure #261 Propagate Hyper error on serve failure
• Implemented CORS header handler middleware #262 Implemented CORS header handler middleware
• Add middleware for catching panics #265 Add middleware for catching panics
• Add templating example with tera #267 Add templating example with tera
• Adjust docs for consistency #272 Adjust docs for consistency
• Cors middleware extension #275 Cors middleware extension
• Tide on runtime #283 Tide on Runtime
• Set StatusCode for an empty response from () to 204 #285 Set statuscode for an empty response from () to 204
• Rewrite tide-slog to setup a per-request logger instance and support slog-scope #287 Update tide-slog
• Add doc example showing query parameter extraction #291 Add doc example showing query param extraction

Page 1

• querystring: replace dependency serde_urlencoded with serde_qs #299 Replace serde_urlencoded with serde_qs
• removed existential_type feature #301 Remove existential_type feature
• Fix clippy error in static file example #303 Fix clippy error in static file exmaple
• cookies: is &mut self required? #317 Cookies: is &mut required?
• CORS middleware: better handling of Origin #318 CORS Middleware: better handling of Origin
• Nested router example #331 Nested router example
• feat(core): If JSON Serialize failure return 500 and Error message #332 if JSON serialize failure return 500 and error message
• Remove dev dependency on the runtime crate #334 Remove dev dependency on Runtime crate

[prasannavl]

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.

[yoshuawuyts]

@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.

[dtolnay]

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.

[prasannavl]

@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!