proposal: use http.HandlerFunc instead of the 2 custom handler funcs

[urandom]

In go 1.7, the request has an extra context field. It can be used for storing the parameter map and the panic data, instead of using custom handler functions with an extra parameter.

I've played around with the idea in this fork:
https://github.com/urandom/httptreemux

To me it seems a good usage of the context is to store the whole parameter map as a single key. That's because usually when people have url parameters, they want all of them, as opposed just one or two items. The retrieval is also faster, since the context is essentially a linked list. The panic handler is quite similar.

I've added two functions in in the package, RequestParams and RequestError, though I'm not sure if the names are perfect.

If you approve of this proposal, perhaps it would be best if you make these changes in a version 5 branch, so you can still have version 4 if you want to break the api in some other way for the go1.6 and lower.

[dimfeld]

This is very interesting. I definitely like the idea and am really glad to see context becoming more integrated into the Go standard library. I agree with your philosophy on storing the entire parameters map as a single key in the context.

My main concern, of course, is with breaking backwards compatibility. Although a lot of other router packages are much more widely used, this package has been around longer than most of the Go vendoring solutions and is in at least one training course and a couple of commercial uses, and I would prefer not to inconvenience them if I can help it.

That said, I don't think this is an insurmountable problem. The first thing that comes to mind is that on Go 1.7 there would be two ways to create the router. The object returned by the existing New function would continue to expose the same interface as it does now with the custom HandlerFunc type, but would wrap the supplied handler in a standard http.Handler that uses something like your RequestParams function to extract the params, and then pass it to the new Context-aware router.

Then, some other constructor function would just create the new version of the router that uses native handlers and Contexts. I'm not sure exactly what this one would be called, but it would become the preferred way to create a router.

I think it shouldn't be too hard to factor out the parts of the code that will require 1.7 into their own files so that it can build them conditionally, and it doesn't sound like any of the complex parts of the code are involved so the additional code maintenance overhead should be minimal. I'll have to think more about the best way to make that all happen, but I definitely would like to do this. Thanks for mentioning it!

[guregu]

Great idea!
For what it's worth, I do the same thing in my framework kami: sticking the params/panic value into the context. It would be cool if this were built into httptreemux. Then I could make kami more of a middleware package than a whole framework, which is a goal I have after 1.7 hits and context gets standardized. I'm not sure how much I can do without breaking backwards compatibility, but that's another story.
I use the same kind of wrapping pattern that @dimfeld described to support multiple kinds of HTTP handlers and it works well. The only negative is one weird anonymous function in your call stack, which is fine IMO.
BTW, kami is used commercially in a few companies in Japan, so httptreemux definitely has more than just a couple commercial uses. Thanks for the great package!

[dimfeld]

I have something that passes tests on Go tip in the contextmux branch. Biggest problem right now is that adding things to the Context causes garbage to be generated and adds extra time due largely to the copy semantics of adding things to a Context. I'm not sure if there's a way around this though, and the continued support of the original version of the software may be good enough here.

I also need to figure out a good way to publish both the original version and the Context-aware version of the software. I was hoping to use something like gopkg.in but it only works with tags and branches that look like version numbers, which isn't the end of the world but certainly isn't ideal. A fork may be another option though I'd prefer not to go that route if possible.

[patrickrand]

Any plans to move forward with this? I completely agree about the preserving backwards compatibility. What about a second router type, which uses contexts?

[dimfeld]

That's my hope, to just use two different types. Integrating them into the same code base without duplicating a ton of code proved a bit tricky but I'll have another go at it before long, work schedule permitting.

[patrickrand]

Gotcha. If you don't mind, I'd be interested in taking a stab at what you've started in the contextmux branch and some of the talking points mentioned in this thread. Are you open to pull-requests on that feature branch?

[dimfeld]

That sounds great. Thanks!

On Tue, Sep 6, 2016 at 11:58 AM, Patrick notifications@github.com wrote:

Gotcha. If you don't mind, I'd be interested in taking a stab at what
you've started in the contextmux branch and some of the talking points
mentioned in this thread. Are you open to pull-requests on that feature
branch?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABTl1sw5snzYukRHWMtnyJdikjT4v6_Cks5qneH4gaJpZM4IVUTZ
.

[dimfeld]

Fixed by #33