Add old mailing list archives

1 files changed, 418 insertions, 0 deletions

diff --git a/archives/extend/2012-November.txt b/archives/extend/2012-November.txt
new file mode 100644
index 00000000..dedac05f
--- /dev/null
+++ b/archives/extend/2012-November.txt
@@ -0,0 +1,418 @@
+From essen at ninenines.eu  Tue Nov 13 10:04:17 2012
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Tue, 13 Nov 2012 10:04:17 +0100
+Subject: [99s-extend] Proposal for Cowboy Routing
+Message-ID: <[email protected]>
+
+Hello!
+
+I have put my thoughts on routing at the following gist:
+
+   https://gist.github.com/4064759
+
+Please comment or cry in terror if you're against it!
+
+Thanks.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From thomas at oinksoft.com  Tue Nov 13 15:12:59 2012
+From: thomas at oinksoft.com (Thomas Allen)
+Date: Tue, 13 Nov 2012 09:12:59 -0500
+Subject: [99s-extend] Proposal for Cowboy Routing
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <[email protected]>
+
+On Tue, Nov 13, 2012 at 10:04:17AM +0100, Lo?c Hoguin wrote:
+> Hello!
+> 
+> I have put my thoughts on routing at the following gist:
+> 
+>   https://gist.github.com/4064759
+> 
+> Please comment or cry in terror if you're against it!
+
+I think that this looks very good. The current router handles all of my
+use cases, and this bit of sugar will definitely help to speed up
+development.
+
+As an aside, have you considered adding optional slash-add
+functionality, so that /a/b will match "/a/b/"? This is pretty easy to
+set up at the server level, but the front-line server doesn't know about
+our dispatch rules and so it doesn't know if there is a matching
+dispatch rule for the slash-added version of a given URL.
+
+Thomas
+
+
+From essen at ninenines.eu  Tue Nov 13 15:14:03 2012
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Tue, 13 Nov 2012 15:14:03 +0100
+Subject: [99s-extend] Proposal for Cowboy Routing
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+On 11/13/2012 03:12 PM, Thomas Allen wrote:
+> On Tue, Nov 13, 2012 at 10:04:17AM +0100, Lo?c Hoguin wrote:
+>> Hello!
+>>
+>> I have put my thoughts on routing at the following gist:
+>>
+>>    https://gist.github.com/4064759
+>>
+>> Please comment or cry in terror if you're against it!
+>
+> I think that this looks very good. The current router handles all of my
+> use cases, and this bit of sugar will definitely help to speed up
+> development.
+>
+> As an aside, have you considered adding optional slash-add
+> functionality, so that /a/b will match "/a/b/"? This is pretty easy to
+> set up at the server level, but the front-line server doesn't know about
+> our dispatch rules and so it doesn't know if there is a matching
+> dispatch rule for the slash-added version of a given URL.
+
+/a/b already matches /a/b/.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From thomas at oinksoft.com  Tue Nov 13 15:35:29 2012
+From: thomas at oinksoft.com (Thomas Allen)
+Date: Tue, 13 Nov 2012 09:35:29 -0500
+Subject: [99s-extend] Proposal for Cowboy Routing
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+On Tue, Nov 13, 2012 at 03:14:03PM +0100, Lo?c Hoguin wrote:
+> /a/b already matches /a/b/.
+
+Sorry for not being more precise: /a/b would result in a 301 redirect to
+/a/b/
+
+Thomas
+
+
+From essen at ninenines.eu  Tue Nov 13 15:41:35 2012
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Tue, 13 Nov 2012 15:41:35 +0100
+Subject: [99s-extend] Proposal for Cowboy Routing
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]> <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+On 11/13/2012 03:35 PM, Thomas Allen wrote:
+> On Tue, Nov 13, 2012 at 03:14:03PM +0100, Lo?c Hoguin wrote:
+>> /a/b already matches /a/b/.
+>
+> Sorry for not being more precise: /a/b would result in a 301 redirect to
+> /a/b/
+
+Oh alright. Well they are equivalent URLs, so if you really need to 
+redirect I would do so in the handler directly, or through a request hook.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From thomas at oinksoft.com  Tue Nov 13 16:12:14 2012
+From: thomas at oinksoft.com (Thomas Allen)
+Date: Tue, 13 Nov 2012 10:12:14 -0500
+Subject: [99s-extend] Proposal for Cowboy Routing
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+On Tue, Nov 13, 2012 at 03:41:35PM +0100, Lo?c Hoguin wrote:
+> Oh alright. Well they are equivalent URLs, so if you really need to
+> redirect I would do so in the handler directly, or through a request
+> hook.
+
+I suppose this suggests my next question ... how would one accomplish
+this right now in Cowboy? I hope I'm correct in assuming that this will
+involve cowboy_dispatcher:match/3 in an onrequest fun, but I do not
+understand how I will use match/3 with what I get from
+cowboy_req:path/1.
+
+Thomas
+
+
+From essen at ninenines.eu  Tue Nov 13 16:22:48 2012
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Tue, 13 Nov 2012 16:22:48 +0100
+Subject: [99s-extend] Proposal for Cowboy Routing
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]> <[email protected]>
+ <[email protected]> <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+On 11/13/2012 04:12 PM, Thomas Allen wrote:
+> On Tue, Nov 13, 2012 at 03:41:35PM +0100, Lo?c Hoguin wrote:
+>> Oh alright. Well they are equivalent URLs, so if you really need to
+>> redirect I would do so in the handler directly, or through a request
+>> hook.
+>
+> I suppose this suggests my next question ... how would one accomplish
+> this right now in Cowboy? I hope I'm correct in assuming that this will
+> involve cowboy_dispatcher:match/3 in an onrequest fun, but I do not
+> understand how I will use match/3 with what I get from
+> cowboy_req:path/1.
+
+No, just check that cowboy_req:path/1 ends with $/, and if it doesn't 
+then redirect.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From dch at jsonified.com  Tue Nov 13 16:42:53 2012
+From: dch at jsonified.com (Dave Cottlehuber)
+Date: Tue, 13 Nov 2012 16:42:53 +0100
+Subject: [99s-extend] Proposal for Cowboy Routing
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <CAL+Y1nunQttGU4=nTQkUZ6tfx7xAi+X4aDJeWAAHnFKsC3C81w@mail.gmail.com>
+
+On 13 November 2012 10:04, Lo?c Hoguin <essen at ninenines.eu> wrote:
+> Hello!
+>
+> I have put my thoughts on routing at the following gist:
+>
+>   https://gist.github.com/4064759
+>
+> Please comment or cry in terror if you're against it!
+>
+> Thanks.
+>
+> --
+> Lo?c Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+I actually commented on the gist, here's a copy for the ML:
+
+== dch ==
+
+Looks very useful for me. I've not heard of imbrication until today, I
+assume it is closest to nested optional components as used above.
+
+Having regex capability in the constraints would be great:
+
+{"/cars/:name/:color", [{color, in, [blue, red, pink]}], Handler,
+Opts} might be {"/cars/:name/:color", [{color, regex, "^(blue | red |
+pink)$", [other_re_parameters]) , Handler, Opts} for example.
+
+== Lo?c ==
+
+Yes, regex will be a possible constraint. Also checking for integer
+value. Not sure what else we'll want.
+
+A+
+Dave
+
+
+From essen at ninenines.eu  Tue Nov 13 16:46:15 2012
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Tue, 13 Nov 2012 16:46:15 +0100
+Subject: [99s-extend] Proposal for Cowboy Routing
+In-Reply-To: <CAL+Y1nunQttGU4=nTQkUZ6tfx7xAi+X4aDJeWAAHnFKsC3C81w@mail.gmail.com>
+References: <[email protected]>
+ <CAL+Y1nunQttGU4=nTQkUZ6tfx7xAi+X4aDJeWAAHnFKsC3C81w@mail.gmail.com>
+Message-ID: <[email protected]>
+
+On 11/13/2012 04:42 PM, Dave Cottlehuber wrote:
+> On 13 November 2012 10:04, Lo?c Hoguin <essen at ninenines.eu> wrote:
+>> Hello!
+>>
+>> I have put my thoughts on routing at the following gist:
+>>
+>>    https://gist.github.com/4064759
+>>
+>> Please comment or cry in terror if you're against it!
+>>
+>> Thanks.
+>>
+>> --
+>> Lo?c Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>
+> I actually commented on the gist, here's a copy for the ML:
+>
+> == dch ==
+>
+> Looks very useful for me. I've not heard of imbrication until today, I
+> assume it is closest to nested optional components as used above.
+>
+> Having regex capability in the constraints would be great:
+>
+> {"/cars/:name/:color", [{color, in, [blue, red, pink]}], Handler,
+> Opts} might be {"/cars/:name/:color", [{color, regex, "^(blue | red |
+> pink)$", [other_re_parameters]) , Handler, Opts} for example.
+>
+> == Lo?c ==
+>
+> Yes, regex will be a possible constraint. Also checking for integer
+> value. Not sure what else we'll want.
+
+I'll add to that that in the case of integer, we could very well bind 
+the value as an integer instead of as a binary, and avoid all these 
+pesky list_to_integer(binary_to_list(Value)).
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From thomas at oinksoft.com  Tue Nov 13 17:10:04 2012
+From: thomas at oinksoft.com (Thomas Allen)
+Date: Tue, 13 Nov 2012 11:10:04 -0500
+Subject: [99s-extend] Proposal for Cowboy Routing
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+On Tue, Nov 13, 2012 at 04:22:48PM +0100, Lo?c Hoguin wrote:
+> No, just check that cowboy_req:path/1 ends with $/, and if it
+> doesn't then redirect.
+
+OK, so what I'm going for is to actually check for a valid URL with the
+slash. I got it to work in current cowboy, but shield your eyes ...
+
+I do this "middleware" thing often ... this might be a misnomer as I
+think some definitions of middleware specify that it be able to wrap the
+request *and* the response. I digress ...
+
+    %%% foo_app.erl:
+
+    {ok, _} = cowboy:start_http(http, ?ACCEPTORS,
+        [{port, ?PORT}],
+        [{dispatch, Dispatch},
+         {onrequest, fun(Req) ->
+             foo_middleware:all(Dispatch, Req)
+          end}]
+    ),
+
+
+    %% foo_middleware.erl:
+
+    -define(MIDDLEWARE, [
+        fun foo_middleware:slash/2,
+        fun foo_middleware:session/2,
+        fun foo_middleware:user/2
+    ]).
+
+    all(Dispatch, Req) ->
+        lists:foldl(fun(F, CurReq) -> F(Dispatch, CurReq) end, Req,
+            ?MIDDLEWARE).
+
+    %% ...
+
+    slash(Dispatch, Req) ->
+        {Path, _} = cowboy_req:path(Req),
+        case binary:last(Path) of
+            $/ -> Req;
+            _ ->
+                SlashPath = <<Path/bitstring, "/">>,
+                {Host, _} = cowboy_req:host(Req),
+                Match = cowboy_dispatcher:match(Dispatch, Host,
+                    SlashPath),
+                case element(1, Match) of
+                    ok ->
+                        cowboy_req:reply(301,
+                            [{<<"Location">>, SlashPath}], <<>>, Req);
+                    error -> Req
+                end
+        end.
+
+So, I assume that any path not ending in "/" won't match. Another
+version of this could toss that assumption, but then you're performing
+an extra match on every request ... much better to use a '_' rule in
+that case.
+
+One thing that is icky about using a fallback '_' handler, and the
+reason I've elected to use onrequest for this example, is that I do not
+see a way to access cowboy_protocol's state.dispatch to access these
+rules. So, I enclose them in my `onrequest` fun. Would it be possible to
+expose Dispatch? This has many applications, particularly for URL
+reversing.
+
+Perhaps I am missing several things ;^)
+
+Thomas
+
+
+From essen at ninenines.eu  Thu Nov 29 11:46:10 2012
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Thu, 29 Nov 2012 11:46:10 +0100
+Subject: [99s-extend] Proposal for Cowboy Routing
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <[email protected]>
+
+On 11/13/2012 10:04 AM, Lo?c Hoguin wrote:
+> Hello!
+>
+> I have put my thoughts on routing at the following gist:
+>
+>    https://gist.github.com/4064759
+>
+> Please comment or cry in terror if you're against it!
+
+I have added more infos and changes as you can see in the comments here: 
+https://gist.github.com/4064759#comments Please feedback.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+