one of the things that let me drop libCurl in horror was the missing type safety. The so-called easy interface provides a function which basically accepts everything during compilation, and then simply crashes during execution when these arguments were not good...

This is why I searched for networking frameworks once more and stumbled over Poco. Great framework! We ended up replacing not only libCurl but also libXML++ and log4cxx.

But: One thing that bugs me is the way to get/set properties of Poco::Configurable objects!

IMHO it would be much better to have specific functions for each property. This way, a lot of mistakes could be detected by the compiler instead of running into an exception.

For example, the line satisfies the compiler but causes an exception at runtime:

fileChannel->setProperty("rotiation", "100");

It would be much harder to do it wrong with a specific property function like this:

The reason for the Configurable class is that we want to be able to configure properties in a generic way in configuration files (see the Poco~058~~058~Util~058~~058~Application samples). I agree that it would be nice to have type-safe setter functions in the various channel implementations. However, the usual way to configure logging is via a configuration file, so we had not much use for these functions. If someone wants to add them, go ahead.

> we are using a type-safe configuration framework. Thus, it seems a bit weird to create strings from the numbers in order to set the properties (:wink:)

Well, I'm not quite sure what to make of 'type-safe configuration framework' statement. While you are right when you say that in some instances it may be surprising to have a runtime failure, sometimes it is indispensable to be able to load configuration at runtime. And there is no other way to load a number from a configuration file (or get it from command line) than as a string of characters which then must somehow be converted into a number. The conversion obviously may fail - this problem hits in the heart of dynamic/static paradigm difference. I believe that neither is perfect (or, to put it another way, each has it's up and down sides). In medio stat virtus - we try to find a healthy balance.

> I'll take a look at comparable code (GÃ¼nter pointed me to FormattingChannel for reference) and probably provide you with some new methods.

I'm not sure what Guenter is aiming at, but your proposal for setRotationSizeInBytes(const unsigned int bytes) is fine with me in principle - const is unnecessary, though, and unsigned will likely cause compiler warnings and create a need for casts. Anyway, I would not mind adding a set of functions along that line to the current interface and modify the current implementation to use those. So, setProperty(string, string) would still remain in the interface, it would just be implemented in terms of setRotationSizeInBytes(), setRotationSizeInKBytes(), setRotationSizeInMBytes etc , which would also be available for direct invocation in type-safe scenarios. Or, even better would be something like this: