> 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
[email protected]<mailto:[email protected]>
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
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
