<div dir="ltr">(Sorry for the delay, was away for the weekend.)<br><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 24, 2015 at 2:05 AM, Greg Weber <span dir="ltr"><<a href="mailto:greg@gregweber.info" target="_blank">greg@gregweber.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, that is all very clear. My contention is that one should not have overlapping routes, particularly when mounting an Application.<div>If an Application is mounted at /route, then it should be clear that /route* should belong to the Application.</div><div><br></div><div>For example, with Yesod, Yesod "stands in front", but one often mounts wai-app-static at /static and Yesod will statically enforce that you don't create another static/* route anywhere else.</div><div><br></div><div>What is the use case for having one framework "stand in front" such that it requires overlapping, or what is the use case for overlapping otherwise?<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br></div></div></div></blockquote><div>Well, my thought was that Application is, modulo this one problem, already a way of sharing handlers (or sets of handlers) between frameworks. If overlaps are handled nicely, one can combine different web frameworks very neatly. This seems to achieve the original aim, but maybe I'm missing some of the motivation for a common handler?<br><br></div><div>As for a use case for standing-in-front, it's sort of a nice way to have something like a reverse proxy that captures some endpoints rather than proxying them to the underlying service, without the actual overhead of  external requests. I imagine there are other use-cases.<br><br></div><div>Finally, it seems like if we had a good story about Applications working anywhere - in particular, converting one or more endpoints to Application and then mounting them in the same place not changing the behaviour of the overall Application - it would be quite easy for all web frameworks to apply Middleware to a subset of endpoints rather than all of them.<br></div></div></div></div>