On Mon, Mar 21, 2011 at 2:44 AM, Emre Türkay <[email protected]> wrote: > Hi Dean, > > While looking at the documentation I see that the handler is originally > designed to be a function object.
Yep. > That's nice, so the application developer can: > > - Provide a function if the case is a simple one, or > - If the implementation needs state information, provide a class with a > function call operator overloaded. > Well, not really... > However, the call to the Handler::log() brakes that simplicity, the handler > is forced to be a class. > Below are the possible solutions to this problem, with each having their own > pro & cons (mostly taste related). > > 1. Provide an extra error argument to the function. This is confusing because it makes the the function handle two different things. > 2. Handler::log() assumption is fine, let's force the implementation to be a > class with specific > handle_data() and handle_error() functions. Not really. The Handler::log(...) assumption is meant to be a contract between the handler and the server implementation. > 3. Provide 2 different handler functions, one for data and one for error. > This can be done without changing the way things are done as it is. > So I have provided an interface to handle all. I think being easy is nothing > to do with this. > Here, the interface to the application developer is easy, and the > implementation is a little > bit complicated. > Unfortunately, here's the problem with trying to support all three of the things above: 1. There's no "one way" to do it. Because of that you end up with complications that are really unnecessary especially since everything you want to do can be done with the current implementation already. 2. I don't still understand why you would want to have just a function when you still have to worry about synchronization and connection state in the handler implementation. The reason why I'm forcing the server handler to be a type/class is so that data touched by the handlers are actually encapsulated in the handler. 3. There's a way to adapt any function in a type that has the `log` function so that it can be used as a handler to the server. I can give an example when I get more time to do it. > By the way there is no need of the template argument Handler in this > implementation. > Which is bad because your compiler cannot optimize the parts where the handler is being called if you just hold a boost::function to the handler. ;) I would be more interested in a service framework which would allow anyone to map things like 'GET /' or 'POST /' to actual handlers. That can be built on top of the existing interface and if this is what you're looking at doing, I can share some thoughts with you on how to do that instead. In the meantime a pull request to the 0.9-devel branch to port all Handler::log(string_type const &) to become Handler::log(boost::system::error_code const &, string_type const &) would be most appreciated to minimize the interface breakage. I also would like to see if you can find a way to remove the Handler::log requirement by making the error function handler be made part of the server constructor instead -- and maybe logic to use the Handler::log if it's defined, or use the error handler function defined in the server constructor. What do you think about that? :D Thanks and HTH > On Mar 20, 2011, at 12:04 PM, Dean Michael Berris wrote: > >> On Sat, Mar 19, 2011 at 9:22 PM, Emre Türkay <[email protected]> wrote: >>> Hi Dean. >>> >>> What do you say about this interface? Take a look at the various possible >>> handlers. >>> >> >> Hmmm... I don't understand what you're trying to accomplish here. Care >> to elaborate? If it's just a matter of providing an error handler, >> that should be really *easy* and not this complicated. I appreciate >> the code, but I don't know what problem you're trying to solve here. >> >> -- >> Dean Michael Berris >> http://about.me/deanberris > > -- Dean Michael Berris http://about.me/deanberris ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
