[Developers] Suggestion: New API CCTK_Announce
Tom Goodale
goodale at cct.lsu.edu
Fri Jun 3 10:59:20 CDT 2005
Hi,
On Fri, 3 Jun 2005, Jian Tao wrote:
>> Erik proposed a new API
>>>
>>> CCTK_Announce ("keyword", "value")
>>>
>>
>> We might also add a "how important is this?" integer argument, perhaps
>> with semantics similar to those of the similar argument to CCTK_VWarn().
>> This would help distinguish important announcements from less important
>> stuff...
>
> Yes, the problem could be solved by introducing "levels" for CCTK_INFO.
>
> We can set the default INFO level to be zero and users can implement their
> own routines to take care of other levels of INFO by using callback mechanism.
This is all sounding very suspiciously like the CCTK_Log (or Syslog)
functionality which was a planned 4.1 feature; e.g.
int CCTK_Log(int level, const char *tag, const char *message)
or something like that, taking into account Erik's suggestion for an
announce API. Level would be something like the levels we have for Warn
at the moment, plus an INFO, and maybe more; e.g. syslog(3) has
LOG_EMERG
system is unusable
LOG_ALERT
action must be taken immediately
LOG_CRIT
critical conditions
LOG_ERR
error conditions
LOG_WARNING
warning conditions
LOG_NOTICE
normal, but significant, condition
LOG_INFO
informational message
LOG_DEBUG
debug-level message
I don't know if we want to have a significance argument as well to say how
significant an informational or debug message is - I suspect that is
probably just duplicating functionality which should properly be in the
level.
Callbacks should receive all the above arguments, plus thorn name, and
perhaps a flag to say if something has come from the flesh or a thorn
(although that is determinable from the 'thorn' argument as it is done at
the moment).
I had thought to have parameters which could be used to choose which
things go where, sort of like a /etc/syslog.conf does.
If someone would like to take these ideas, propose a concrete API for the
Log function and the callbacks, and semantics, and write a thorn, that
would be great. ( Obviously if it is in a thorn it wouldn't be CCTK_Log
8-)
The thorn itself could have some parameters which select events based upon
some matching criteria and dumps data to a set of files, or this could
(and probably should) be done in a separate thorn as an example of using
the callbacks (even if it is in the same thorn it should of course use the
callbacks).
Cheers,
Tom
More information about the Developers
mailing list