[web-devel] ALPHA: http-types 0.1

[Michael Snoyman]

It's looking very good. A few minor points:

* urlEncode will only work for query-string encoding: there are
different encoding rules depending on which part of the URL we're
dealing with. For example, in the path info, a question mark is
reserved IIRC.
* The docs for StdMethod still refer to OtherMethod.
* I would personally like to see parse/renderPathInfo (however you
want to call it) in this package. Would you accept a patch? For that
matter, if I see other functions that I think could logically be
included here, would you accept a patch?
* I hadn't thought of having the header* things generate a pair, I
think it's a nice touch.

Let's let the dust settle on this package, and on WAI, and then I'll
likely start moving WAI and http-enumerator over to this. I appreciate
the rename to CIByteString, it makes the transition easier.

Michael

On Sat, Feb 5, 2011 at 5:38 PM, Aristid Breitkreuz
<aristidb at googlemail.com> wrote:
> http-types 0.3.0 contains a small, but breaking, change:
> old: renderMethod :: StdMethod -> ByteString
> new: renderStdMethod :: StdMethod -> ByteString ; renderMethod :: Either
> ByteString StdMethod -> ByteString
>
> Aristid
>
> 2011/2/4 Aristid Breitkreuz <aristidb at googlemail.com>
>>
>> Christian, I incorporated your approach of defining the ADT, and Michael's
>> suggestions into
>> *tada*
>> http-types 0.2.0 - http://hackage.haskell.org/package/http-types-0.2.0
>> Features:
>> * StdMethod is an enumeration without OtherMethod constructor, containing
>> only RFC 2616 standard HTTP methods.
>> * parseMethod :: ByteString -> Either ByteString StdMethod (I think the
>> type says all).
>> * There are a few pre-defined Headers (headerAccept...)
>> * urlEncode / urlDecode
>> * Parsing and rendering of query strings (Query / SimpleQuery).
>> I hope this is closer to what most people would consider a nice version.
>>
>> Aristid
>>
>> 2011/2/4 Christian Maeder <Christian.Maeder at dfki.de>
>>>
>>> Am 04.02.2011 11:49, schrieb Christian Maeder:
>>> > The disadvantage for just strings are possible spelling errors. With
>>> > constants or constructors spelling errors are detected by the compiler
>>> > (but you still can confuse constants having the same type).
>>>
>>> Therefore just having
>>>
>>>  type Method = ByteString
>>>
>>> is also less safe, because constants for methods and i.e. header names
>>> (if they are also just byte strings) can be mixed up without type errors.
>>>
>>> Better would be a newtype wrapper around byte strings (or just strings):
>>>
>>>  newtype Method = M ByteString
>>>
>>> But I do not want to interfere with Michael Snoymann's compatibility
>>> issues for wai.
>>>
>>> Cheers Christian
>>
>
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
>