Using path based dispatch and listener lifetime

Question

First of all thank you putting together Casablanca, the few hours I've spent playing around with the library have been productive and pleasurable.

One comment I have, and perhaps I'm missing something in the way the library is supposed to be used, is that when using path-based dispatching one ends up with a proliferation of listeners which tend to have the same lifetime but each of which has to be opened and closed individually. It was the only thing (apart from the mix of wstring/string that has been mentioned elsewhere) that felt slightly jarring when using the API.

I felt like it would be more comfortable were the API able to do:

auto listeners = http_listeners::create( baseAddress )
    .support( "/path/to/resource1", methods::GET, functor1 )
    .support( "/path/to/resource2", methods::GET, functor2 ) 
    /* etc */ 
    .support( "/another/resource", methods::PUT, functorN );

// opens all of the underlying listeners
listeners.open(); 

// ...

listeners.close();

as a convenient mechanism to manage the lifetime of all of the related listeners.

Russ

Answer 1

Russ,

This kind of feedback is exactly why we thought having an early release would be a good idea!

I like the suggestion, it seems very practical. We will definitely consider it in the final design (as well as address the string/wstring issue).

(Also, let me say I'm sorry for not getting back earlier, it was a very busy weekend at home... :-))

Thanks,

Niklas

Answer 2

Thanks for the response.

On a tenuously related question (and one I can't see the answer to already elsewhere in the forums), are the error codes returned by http_listener::open() documented anywhere? I'm receiving a failure code of 5 on one machine in code which is working fine on other desktops and couldn't spot any definitions on a scan through the SDK contents.

I'm also curious given the heavy use of other C++11 features throughout the library, is there a reason why std::error_code isn't appropriate for use instead of the unsigned int return codes?

Answer 3

The error codes are meant to be whatever the underlying OS is providing. In this case, I believe 5 is ERROR_ACCESS_DENIED. It's hard to tell from your description which Win32 call that the code is making (I assume you are not running under IIS) that produces this error, but I would presume it has something to do with opening ports. Is there a log message? If you are using your own executable to host the listener, turn on the default logger, which will go to STDOUT. See the TrivialServer sample for how to get the default log going.

On std::error_code -- no particular reason. We should consider using that instead.

Niklas