Extract parts of the project that should be separate extensions

[CrowdHailer]

Reduce the project to be focused on the core value of Raxx providing an interface between frameworks and servers.

Checklist

• [x] Remove mount field on Raxx.Request
• [x] Extract Raxx.BasicAuth
• [x] Extract Raxx.Session
• [x] Extract Raxx.Logger
• [x] Extract Raxx.RequestID
• [x] Delete Raxx.SimpleClient (it is a nice project but I don't maintain it and I don't think anyone uses it)
• [x] Finish Raxx.Context
• [ ] remove code with warnings e.g. old router format, wait one more breaking change?
• [ ] 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. Could just depend on EEx

Optional Checklist

• [ ] 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
• [x] Extract Raxx.View it is used in some of the default responses in the core behaviours, e.g. Raxx.SimpleServer but I'm not sure that is enough reason to keep it.
  • Add to EExHTML but extends functionality beyond matching EEx also will add mime as a dependency to EExHTML
  • Extract to project Raxx.View (not an extension to raxx because it does not depend on raxx), Gutenberg. It will depend on raxx for the render functions that set content-type

Extracted things moved to Raxx.Kit

Create a middlewares dir in Raxx.Kit containing each middleware as a separate mix project.

Maybe a better name is plugins extensions, not everything will be a middleware.

This will probably make Raxx.Kit the project we direct people to to get started with Raxx. I think I am ok with the idea of Raxx.Kit becoming a micro framework.

[nietaki]

Handful of comments:

1. agreed about removing the mount field in the request object, it's probably not the right level of abstraction for it

2. Do I understand correctly that you want to remove path property on the request in favour of the raw_path? I'm not sure about that one - it's been a staple of Raxx, a useful tool and had the benefit of mapping to the raw path pretty 1:1, with no information loss. What's the reasoning here?

3. Do I understand correctly that you're thinking of moving the middlewares / general purpose tools to Raxx.Kit? As Raxx.Kit is right now, it's just a project generator, and not really a package you would download and use as a library. I think it's good this way and trying to combine them would be confusing to say the least. If we put the commonly used middlewares in Raxx.Kit we'd either need to make it a library, or rely on copying and pasting them behind projects, with pretty inconvenient approach to code reuse and versioning. I think common tools should go in a separate package (raxx_tools?).

4. Similarly, I'm not sure I understand what you mean by "Create a middlewares dir in Raxx.Kit containing each middleware as a separate mix project."

5. I'm really not up to date with EExHTML and Raxx.View, so it's hard for me to have an opinion right now.

I'm probably misunderstanding some things or reading too much into some notes, please correct me where I'm wrong.

[CrowdHailer]

2. let's leave this for now. I think you are probably right we should leave it, but just not 100%
3. I'm thinking of putting them in the raxx.kit git repository, but not as part of the raxx.kit elixir project. see https://github.com/CrowdHailer/raxx_kit/compare/master...raxx-logger
4. just a directory for independent elixir projects inside the raxx.kit git repo

[CrowdHailer]

This issue is probably going to be closed as raxx 0.18.x rather than 1.0 I think as there are several changes we should do one more cycle before committing to 1.0 release