Add syslog logger support.

[thughes]

Adding syslog as a supported logger. This seems like a common enough use-case to be in the main repo.

[thughes]

I don't think the build failure is related to my change (when running scons test locally all the tests pass).

[zaphoyd]

yep, the failure is in one of the timed tests. Travis machines are not always super fast so sometimes there are false positives on those.

[zaphoyd]

I'm not ready to introduce virtual methods to the logging interface. If you resubmit this without the virtual methods I'll accept.

[thughes]

@zaphoyd, I can definitely remove the virtual methods, but just to satisfy my curiosity, can I ask why? (e.g., worries about performance). The reason I marked it virtual (and used C++11's override) in the derived class was so that we would get a compiler error if you changed the signature of the method in the base class.

[zaphoyd]

Sure. A few reasons. Primarily, appropriate tools for the job and not bringing in additional runtime complexity unless it is necessary. WebSocket++'s policy based composition of components (including the logging system) is a compile time operation with no need for runtime polymorphism, as such virtual methods add complexity and overhead that is not needed. Keeping static binding is faster and gentler on caches/branch predictors, allows IDEs and the compiler to provide better error messages, better documentation links, better inlining, and other optimization.

This is particularly important for the logging system which gets invoked in many of the library's critical paths and in many cases those invocations are intended to be inlined into no-ops/branches that always fail, something which virtual dispatch complicates.

With respect to override, the library is required to be useable on non-C++11 systems, so the addition of new C++11 keywords needs to be done carefully. In practice, even without virtual+override, you will still get a compile error if the signature of the write methods change as the call sites in the library itself will change. The policy based design methods will enforce at compile time that all custom policy components implement all required method signatures.

WebSocket++ is designed to be extended via custom policies for certain components (logging, RNG, transport, http parsing). I consider the interfaces that the library uses to talk to these components a part of the public API and subject to the same backwards compatibility and breaking change notifications as the rest of the library. An update to the interface between the library core and policy components would be considered a major API breaking change that would not be made lightly and if done would be be listed prominently in the release notes.

[thughes]

Thanks, that's exactly what I was looking for. Glad to know that changing the logger interface would be considered a major API break.

[ido]

@zaphoyd Excellent explanation. 👍

[thughes]

@zaphoyd Removed the virtual methods and override.