On Wednesday, 27 November 2013 at 08:45:37 UTC, Andrea Fontana
wrote:
Should we consider interoperability with std.path too?
Generally, I think no, though it would be easy enough to get
uri.path as a decoded string and pass it to those functions.
But std.path is a bit different on Windows and Linux (I think;
I've never actually used it), whereas urls have a slightly
different and stricter interpretation (which may be treated like
win or lin depending on the server).
I worked on http protocol, and I don't think that's will be a
big issue. Http client side is not so complex if you need a
working subset. I think we don't need gzip compression in first
release, for example.
Yeah, http is pretty simple. Even gzip isn't really hard.
+1 for an oauth module. It would be very useful to work with
third party api (facebook, google, etc ...) and to write api
too! However I think it depends on http(s) module.
Yup. I wasn't thinking of putting the server code in the
std.net.http, though I have some in my oauth.d (isSignatureValid,
isOauthRequest, etc., the functions that take a Cgi parameter)
I've barely actually used it, so it is probably buggy, but it is
there and wasn't horribly hard to write after getting the client
working.
(The biggest pain with clients btw? Buggy servers! It has gotten
a little better, but when I started with this, Twitter, LinkedIn,
and AWeber, the three I had to use.... all interpreted the spec
slightly differently, so what worked on one wouldn't work on the
other two, and, of course, the error messages are never helpful
and the documentation sucks. Massive pain.)
