On Wed, Feb 2, 2011 at 1:04 PM, Neil Mitchell
Hi
Let's speak practically here about what kind of types we're dealing with:
* Status, including the numeric code and status message. Eg, data Status = Status Int ByteString * Request/response header key. In WAI, I use data CIByteString = CIByteString !ByteString !ByteString, one version being the lowercase, the other the original. * Request/response header value. In WAI, I use ByteString. * Status values like we have in WAI: status200/statusOK, status404/statusNotFound, etc. * A bunch of header keys: hdrContentType, hdrAccept, etc
I think all the above is exactly what should be in the package. You shouldn't include Request/Response, but you should include all the Int/String-like values that users of http need. I also think it should be http-codes or similar, it's not defining a type.
Why not do:
hdrContentType :: IsString a => a
And similarly for all values that are just strings. You eliminate the bytestring package dependency, and nothing will need to know whether things are String, Text, LazyByteString, ByteString or CIByteString (or even Builder values).
You could also have:
data HttpStatus = HttpStatus Int a
statusOK :: IsString a => HttpStatus a
In Hoogle I define a few things like hdrContentType, so if these were all standardized it would be great.
Thanks, Neil
No matter what we will need the bytestring dependency to define the CIByteString datatype. But is there an advantage to this polymorphism? I can't think of a use case for a status message or a header to be anything but a ByteString. There *is* one possible datatype we could include which Johan hinted at: ASCII. We could in theory have: newtype ASCII = ASCII { unASCII :: ByteString } byteStringToASCII :: ByteString -> Maybe ASCII byteStringToASCII bs | S.all isValidAscii bs = Just $ ASCII bs | otherwise = Nothing And so on and so forth for String, also providing some unsafeToAscii functions and an unsafe IsString instace. I know I've wanted this datatype in the past (WAI and mime-mail in particular), but I'm not sure if it provides enough of a benefit to be worth the extra overhead. Michael