New 1.0 roadmap

[CrowdHailer]

This is the follow up to #118, it was decided at least one more breaking release should be done before 1.0

Checklist

• [x] remove code with warnings e.g. old router format
• [x] ~~EExHTML 1.0 release, make it have an optional dependency on Jason. This is because I think EExHTML might remain a dependency of the core raxx to the page that it puts as default callbacks redirect function relies on this.~~
• [x] Rather than configuring the extra status codes Raxx.response({422, "Unprocessable Entity"}) Add a new field to response struct, that is optional. Ace will have to send "Unknown" if it is not set. or nothing in HTTP/2 land which is fine
• [x] Reinstate/Remove skipped tests
• [x] Fix travis for OTP 21.3

Optional Checklist

• [x] ~~Drop the raw_path field on a request Have only path and that should contain the raw binary. Then introduce Raxx.segments(request) to return the split path~~

[CrowdHailer]

Thanks to @lasseebert and his work to remove EExHTML as a dependency (#171) we can drop a 1.0 for EExHTML as a requirement for Raxx 1.0

[CrowdHailer]

Nearly ready for a 1.0 release :tada:

Try the release candidate from hex using, {:raxx, "~> 1.0.0-rc.3", override: true}

My opinions on all that remains is.

1. Don't do anything relating to being able to choose the reason phrase in a response. It can be added as a non breaking change after 1.0
2. remove the final skipped test the router should not make assumptions about what metadata to add as it is intended as a base layer on top of which more sophisticated routing can be built
3. Leave raw_path as it is now.

[nietaki]

I took a quick look through the project and recent changes and There don't seem to be any real blockers for 1.0.

Random notes:

1. I don't think any changes to Middleware/Stack should be breaking for any users. The only thing that can change is the Stack state structure, which is appropriately marked and shouldn't really be relied upon by anyone.
2. I didn't look at all of the recent code changes, but the changelog looks reasonable.
3. Removing the skipped test makes sense. More involved routers with parameter bindings and conventions can be developed later on, with no changes to Raxx core.
4. I'm all for leaving raw_path as it is now.
5. I can try the RC with some old dusty projects this weekend, see if there's any warnings or anything when using it.

One thing that I think might be worth addressing before 1.0: Configuring extra statuses using config/Application.get_env - I don't think there's much value to it, it's the only instance where Raxx depends on the config and I can imagine situations where it leads to some stupid problems. I think I'd be in favour of removing the extra_statuses altogether before 1.0 to not carry it on as baggage.

[CrowdHailer]

Thanks for the comments.

I don't think we can remove extra_statuses without implementing the replacement. We use it and it hasn't caused any problems for us. but that's all I have. I don't think it's the best solution I'm just also not sure it's worth stopping 1.0 for it??

[nietaki]

What I meant with extra statuses is that we could allow for arbitrary {status_code_integer(), status_name_string} tuple in the %Raxx.Response{} status field (and any functions that take the status as an atom or integer).

This way the user could still send arbitrary statuses, but without the need for a global config. It wouldn't be difficult to use either, in your user code you could just define def unprocessable_entity(), do: {422, "Unprocessable Entity"} and use it wherever needed.

I think this would be a clean solution, requiring minimal code changes and making Raxx independent of Mix.Config. Plus I think that the assumption that everything in the user app would like to share the extra statuses might not always be correct.

[CrowdHailer]

I like the proposal. But does it need to be a thing before 1.0? Raxx.request() currently takes atom | integer after it would take atom | integer | {integer, binary That could be added at 1.1?

[nietaki]

My reply from 2 days ago didn't send :/

There's a couple of reasons why I'd like to get that in before 1.0:

• it is an API-breaking change and I think we'd like the API to be a bit more stable after 1.0. For how small of a change this is, I'd understand the resistance against doing it post 1.0
• It's the only place where Raxx depends on Mix.Config and I don't think we're getting a bang for our buck. I think making Raxx independent of the config would make it cleaner / more functional
• With the way it is right now, there's an in-built assumption that all the code sharing the config will use the same extra statuses. This might not always be true

[CrowdHailer]

Alright I'm sold. I do think that when this gets implemented it should go as a 0.19.x release. And exists for a bit in the wild. I will at least get feedback from using it in my own projects

[CrowdHailer]

It is worth noting that HTTP/2 does have reason phrases and HTTP/1.1 can have responses with no reason phrase and you can already pass any integer to Raxx.response

So any status code is already supported by just passing an integer when making the response. I wonder what plug/phoenix/cowboy does

[CrowdHailer]

Going on the points above I have added this test. https://github.com/CrowdHailer/raxx/pull/172/commits/f01963748f52796b063c441a3de9f3b97d9b6a5c

In my opinion that shows that we can handle any status code. if you want words then define a function that returns an integer and use as follows

def my_status(), do: 299

Raxx.response(my_status()

I don't think there is any need to support custom status wording.

[CrowdHailer]

Here's the commit on the next branch https://github.com/CrowdHailer/raxx/pull/172/commits/dd2ee03e54e785d5dac31bce98e7a0b7e45bd8a6