> 1. The logging facility should be implemented as a singleton, i.e. it > should not be necessary to pass in a reference to a log class to all > methods/functions which might want to add a log message.
I think this is a good idea, and in line with common usage of the singleton pattern. However, we should make a few things clear up front: 1a. This is not a universal logging facility in that we want to cover every possible use in any possible code, but tailored to what we need in OPM. Certainly - that was also part of the reason the name OpmLog gave slightly positive connotations. 1b. The logging facility should not be used for all communication with the user, only warnings/errors etc. I think that regular output should not be a part of this, even though that prompts more questions, Why not - that is my ambition? At least in a production setting the simulator will be run in queue system and all output must/will be redirected to a file. By having multiple backends we can send messages many places, including stdout with a common use pattern in the client code. My (maybe unrealistic ??) hope is that the logging system is so good that Joe Developer will rather sprinkle the code with a couple of "Log::addMessage()" instead "std::cout" while debugging/developing. Apart from disagreeing with the API proposed (let's not use new if we do not have to) I support this. Sure. > > 3. The log levels, i.e. Warning, Error and so on should be dynamic; and > each backend should have it's own loglevel. I do not quite understand what you mean by these being dynamic, and I do not think different backends should define their own. These levels are to be used in client code (simulators) where I can imagine such a thing as "Newton failure, report this at Warning level" is something the client would like to do. If the way to specify a Warning changes with the backend then there is no polymorphism here, so I fail to see how that could be done. What I mean; (which might still be a bad idea ?) is : 1. The global log handler manages a set of log levels (i.e. Warning, Error, Message, ....) dynamically. The default will of course be built in, but it should be possible from clientcode to say something like: size_t message_id = Log::addMessageType(); ... ... Log::addMessage(message_id , "This message is tagged with the new message_id tag"); 2. When a backend is instantiated it is instantiated with a mask of the message types it accepts, i.e. ErrorBackend backend( Log.ERROR ); MessageBackend backend( Log.ERROR || Log.MESSAGE || message_id ); // Will include the new message type Then we call Log::addMessage( message_type , "Message ....") Each backend will make it's own decision whether to include the message. Point 2, i.e. that each backend does It's own filtering decision I am quite certain is a good idea, point 1 is maybe overengineering? [Roland: I hope this also answers your question?] _______________________________________________ Opm mailing list Opm@opm-project.org<mailto:Opm@opm-project.org> http://www.opm-project.org/mailman/listinfo/opm ------------------------------------------------------------------- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you
_______________________________________________ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm