Good day guys,
I've been working on/off on the asynchronous HTTP client and I see
that there's quite a number of things missing on the message side to
be able to support the addition of new constructs to future-wrapped
data. Let me explain a little.
Currently, the basic_response template has an interface that allows
wrappers and directives to reach into the guts of the message and then
deal with the members that basic_response defines. Now that I've
standardized the message concept to support wrappers and directives,
it seems this is not enough for the asynchronous futures-based world.
Consider:
struct basic_response {
boost::future<string> status_message;
};
basic_response msg;
msg << status_message("yadda"); // [1]
string s = status_message(msg); // [2]
There's a problem with [1] because the status_message_directive will
have to know that message contains a future, and thus use a promise in
the function operator overload. Using just this construct it will be a
little cumbersome to make things happen, but it's certainly not
impossible.
For [2] it really should be able to know that the tag for the message
is an asynchronous tag. The number of specializations will be a little
crazy if we overloaded for every asynchronous tag we were going to
implement/support. So I made a couple of changes:
1. Message Modifiers. I introduced a new requirement that supports the
following syntax:
status_message(msg, "yadda"); // [3]
boost::promise<string> promised_string;
status_message(msg, promised_string.get_future()); // [4]
The idea for this is that status_message function can do tag
dispatching, based on whether msg is an asynchronous message or a
synchronous message (no pun intended) and "do the right thing".
2. Tag Hierarchies. I also introduced some template metaprogramming
that allows for meta-tagging tags:
namespace tags {
struct async {};
struct http_async_8bit_udp_resolve : async {};
}
I can then implement an "is_async" metafunction on a tag and determine
whether it is derived from tags::async. Then I can dispatch the
implementation on whether to understand futures/promises or just do
the normal thing.
All of this is already in the branch 0.7-devel and I intend to gut the
implementations as well and add more concept checks to ensure that we
fix the wrapper, directives, and modifiers to use concepts all around.
I'll finish up the message-related gutting that I am doing,
implementing the concepts to all the wrappers and directives that are
already there. Hopefully I can settle with something that is
acceptable and extensible.
Let me know if you have any questions or if you have better ideas on
how to make this a little less repetitive (the overloads). I'm not
opposed to doing template metaprogramming -- on the contrary I would
love it more if there was a cleaner way for doing the refactoring.
Thanks in advance guys and I hope this helps!
--
Dean Michael Berris
deanberris.com
|
