<br><br><div class="gmail_quote">On Fri, Mar 19, 2010 at 2:42 PM, Jeremy Shaw <span dir="ltr">&lt;<a href="mailto:jeremy@n-heptane.com">jeremy@n-heptane.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Mar 19, 2010 at 4:22 PM, Michael Snoyman <span dir="ltr">&lt;<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>&gt;</span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As an example of both a unified URL creation framework and persistence framework, I&#39;ve put together a little example of how we could create an &quot;authentication plugin.&quot; For the purposes of our discussion here, we could ignore the persistence piece for now, though I would like to eventually discuss how we could make that better.</blockquote>

<div><br></div></div><div>Yeah, I gotta finish the urlt stuff first before I think about something else ;) </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im"><div> </div></div></div></blockquote><div>I&#39;d prefer to do that too in general, but I&#39;m going to be doing a project next that involves a lot of DB code. I already did one site that used direct SQL generation, and I&#39;d really rather avoid going that route again.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>I wrote a small blog post[1] describing the system. The code relevant for our discussion is broken into two files: WebPlug.hs[2] defines the interface and auth-example.hs[3] is the actual example.</div><div>
<br></div><div>In this version of WebPlug.hs, I&#39;ve included WebPlug as a datatype instead of a typeclass. I don&#39;t actually *use* that datatype here, but I think it would be very useful for higher-level utilities like the quasi-quoter to be able to access the three related functions together.</div>

</blockquote><div><br></div></div><div>Right. I already have a similar datatype in URLT.HandleT. My type also includes a &#39;defaultPage&#39; type which can be used to specify what value &quot;/&quot; should be mapped to. Though, in mine, the dispatch / handleLink function is based on URLT, but that can probably be generalized. As a bonus you also get a Functor instance, and a runSite function that uses the type..</div>

<div><br></div><div>You should really check out URLT sometime :p</div><div><br></div></div></blockquote><div>I thought I had, just didn&#39;t realize that HandleT was relevant to the low-level bit. I&#39;ll try to get through the rest of urlt today.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div></div><div>I am not going to have time to look at this again until Saturday or Sunday. There are a few minor details that have been swept under the rug that need to be addressed. For example, when exactly does should url encoding / decoding take place. It&#39;s not good if that happens twice or not at all.</div>

<div><br></div><font color="#888888"><div><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#888888"><br></font></font></div></font></div></blockquote><div>Just to confuse the topic even more: if we do real URL encoding/decoding, I believe we would have to assume a certain character set. I had to deal with a site that was encoded in non-UTF8 just a bit ago, and dealing with query parameters is not fun.</div>
<div><br></div><div>That said, perhaps we should consider making the type of PathInfo &quot;PathInfo ByteString&quot; so we make it clear that we&#39;re doing no character encoding.</div><div><br></div><div>Another issue in the same vein is dealing with leading and trailing slashes, though I think this is fairly simple in practice: the web app knows what to do about the trailing slashes, and each plugin should always pass a leading slash.</div>
<div><br></div><div>Michael</div></div>