2003-01-03T10:36:57 wolfgangat_private: > More important would be IMO to design the new API in a way > that it is possible to map it to "classic syslog" using simple > C macros. Why limit to macros? I've seen loads of open source projects that include implementations of sometimes-missing routines, like e.g. various printf varients (snprintf, vfprintf, ...). Make one of the first implementations of the new logging API be a simple C version that backends onto syslog(3), and use autoconf to decide whether its needed at build time. What's more, if the implementation made a good easy-to-parse encoding onto the syslog(3) message, this could be the favoured implementation. Combine it with a syslog that fixes the grossest defects of the standard one (replace the idiot partial timestamps with ISO 8601 / RFC 3339; replace UDP with TCP plus simple newline termination to delimit records) and we'd be close to done, no? If we're closing on an implementable design, would it be worth giving some thought to the registration management for the tags? I think we're in agreement that we can't hope to cover every possible need a priori, there needs to be some open-ended flexibility for people to add tags where the existing lexicon doesn't cover their needs. But we really ought to try and find a way to encourage people who run into that situation to submit their new tags to a registry that feeds them back as updates expanding the lexicon --- and ideally the submitter's code shouldn't have to change when an updated lexicon comes out, it should continue just as before, with its "private" tags coinciding with the new standard tags. -Bennett
This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 09:09:29 PST