Re: [cpp-netlib-devel] About Handler::log()

[Dean M. B. <mik...@gm...>]

On Mon, Mar 21, 2011 at 2:44 AM, Emre Türkay <emr...@gm...> 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 <emr...@gm...> 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