Hi Steve!
On Mon, Nov 15, 2010 at 6:11 PM, Steve Hartwell
<ste...@gm...> wrote:
> Dean Michael Berris <mikhailberis@...> writes:
> ...
>> Is anybody able to check out the documentation and see if there are
>> any glaring issues that need to be addressed?
>
> The documentation is coming along well. I'd like to see a little bit on
> the client::request and client::response public API, particularly their
> use on the async variants.
>
Thanks! I'll write up the sections for reference on the Client API
either later today or early tomorrow.
I've just finished the documentation of the Server API. I'm looking to
do something similar for the Client API in discussing the actual
wrappers, directives, and modifiers that are supported by the
client::request and client::response types and instances of those.
>> Feedback would be greatly appreciated.
>
> It's a very impressive library design, and more so given its
> comprehensive use of Boost. I particularly admire your diligence in
> constructing the Concept checks.
>
Thank you. :)
> Having read through recent discussions on Request and Response body
> representations, I have to agree with others that a string type (or any
> container which assumes contiguous storage) is unsuitable for production
> use. Of course, having body representations /constructible/ from
> strings is desirable for the ease of use you are advocating, similar in
> convenience to stringstream.
>
> You may have already considered using the Boost.Iostreams Source concept
> for the client::request body, and the Sink concept for the
> client::response body. I think that chunking, transfer-encoding,
> multipart/form, and MIME layers would be much more manageable with the
> Boost.Iostream Filter concept, too.
>
Yeah, the request/response body representation is a little testy from
the way it's set up right now and the way others want to use it. I was
thinking that for simple web application calls, strings would be
enough -- and I haven't considered streaming files through the client
interface. :D
I haven't considered Boost.Iostreams before and now that you mention
it, it's a good idea to model the concepts or even introduce it as a
dependency of the library. My only worry with this is the added
dependency, which I'm already thinking about cutting down (especially
because some dependencies require externally built libraries).
I am considering a less "greedy" implementation that allows for the
body to be consumed through an Iostream interface wrapping the
Boost.Asio socket in an object that allows for stream-like access.
Maybe playing well with the Boost.Iostreams Source concept would be a
good thing too. This is for the response object.
For the request object, I might consider just taking in a single-pass
range that can be copied around lightly. I'll need more experience
with Boost.Iostream to see if I can require a request's body to be a
"Source" to be more generic about it.
I'll look into that as soon as I release 0.8 with the asynchronous
server implementation. My focus this past few weeks has been the
server side, and I can shift back to the client side in the next
release.
>> Thanks and have a good day guys.
>
> Thanks and best wishes to you.
>
Thanks for sharing your thoughts Steve! They're definitely most appreciated.
--
Dean Michael Berris
deanberris.com
|
