[bind10-dev] Questions on the Logging API

[Stephen Morris]

On 17 Dec 2010, at 14:32, Michal 'vorner' Vaner wrote:

>> The idea is that the messages are replaceable during the build process.  If a site does not supply a replacement message file, the original file supplied with the distribution is used.  And even if a replacement message file is supplied, it is merged with the distribution file, it does not replace it.  In this way, if we were to upgrade BIND and add new messages, BIND would still build with a message replacement file for the previous version even if it did generate warnings about some messages not being replaced.
> 
> Ah, so it wouldn't be possible to change the language just by configuration? It
> does not seem really user friendly.

Well, I was proposing to link them into the code statically for the first implementation, mainly for simplicity.  But there is no reason why the code can't read in the message text at run-time.



> 
>> OK, I see.  You are saying that you might want:
>> 
>>   MULQNAME: a question section may have only one qname, packet received that has 6
>> 
>> ... written to the log file but something like:
>> 
>>  { "id": "MULQNAME", "args": [6] }
>> 
>> ... written to a network port.
>> 
>> Yes, that is do-able...
>> 
>> Perhaps the most difficult part about it is packaging up the various types of arguments.  I would think that the easiest thing is to convert them all to strings at the point at which the message object (containing the condition code and arguments) is created.
> 
> Yes, that's what I meant.
> 
>> <message size><condition code><arg count><string1><\0><string2><\0>...
>> 
>> We would need to be disciplined though.  For the information to be interpreted with later versions of BIND-10, message numbers and meaning of arguments must not change.  So new messages should only be added to the end of the message file and messages that become unused are never removed.
> 
> Well, if it was in the log file directly, we could just skip the unknown ones.
> But yes, we would have to never change the numbers (which we don't want anyway I
> guess).

And the temptation to sort the file alphabetically after you've added a few messages would have to be resisted :-)



>> I'm not sure what you mean when you say "the compiler could pick the messages out of the files by itself"?  It needs to know what to pick - which leads us back to the idea that each message has some unique identification.
> 
> Well, we could mark them somehow, like:
> log.error(TRANSLATABLE(MULQNAME, "a question section may have only one qname, packet received that has %1"), 6);
> 
> And the message compiler would look trough the code to find TRANSLATABLE.

That's an interesting idea, although I'm not clear how we would preserve existing message numbers if we add or remove files.  What do other people think - is it worth doing something like this?  Is the overhead worth it to avoid adding

   MULQNAME, "a question section may have only one qname, packet received that has %1"

to one file and

   log.error(MULQNAME, 6)

to the source code?


> 
>> The wiki article suggested that, putting the facility code into the most significant 16 bits and the error code into the least significant 16 bits.  So a single 32-bit number holds both bits of information. (In fact you can put a lot of information into a 32-bit number - see for example the information encoded into a VMS condition code -  http://h71000.www7.hp.com/doc/82final/5973/5973pro_022.html)
> 
> I probably missed that one in the article. But then, wouldn't it be better to
> just have 2 parameters for the logging function? We don't need to compress it
> that much (and if we wanted, we could have the parameters 16bit, but using
> unsigned, no matter what it is on the platform, seems OK). I think it would be
> more readable to write it that way and less error prone.

We can do, but why not combine the facility and error number into one symbol? We can even name the symbol to include facility, e.g. DLB_MULQNAME (DLB = DNS Library).


Stephen