On Wed, May 26, 2010 at 3:04 AM, Chris Eidhof <[email protected]> wrote: > Hey all, > > Again, congratulations on the release. Everything looks quite awesome: the > documentation, the design, the tests and benchmarks. >
Thanks! > I have two comments on the design of the URL matching: > > Consider matching the "echo/:s" URL. It puts a key "s" with the corresponding > values in rqParams. Why did you make this choice? Have you considered putting > it in a different data structure? I can see why it's useful, but is it > possible this way to accidentally overwrite POST-data? This solution feels > too much like PHP's $_REQUEST. > rqParams is of type Map ByteString [ByteString]. We don't overwrite POST-data but append it to the list of values that the key already points to. > The second question: if we separate the URL handling from the response > building, it might be possible to build even faster code. For example: if we > know all the possible URL structures in advance, we can put all those URLs in > a fast Trie-structure. Is this something you are willing to consider? > The route function (http://snapframework.com/docs/latest/snap-core/Snap-Types.html#v%3Aroute) does just that. It takes an associative list of routes and actions and basically builds a trie (/-separated component wise, not character-wise). Hope this helps, -- shu _______________________________________________ Snap mailing list [email protected] http://mailman-mail5.webfaction.com/listinfo/snap
