[Bro-Dev] &log attribute

Seth Hall seth at icir.org
Tue Mar 22 06:24:49 PDT 2011

There is a clarity issue with the current style of the new scripts I've been writing with where the state is stored before it's logged.  My typical model has been to define two record types; Module::Info and Module::Log.  An example looks like this....

type Log: record {
	uri: string;
	host: string;

type Info: record {
	log: Log;
	pending_requests: SomeOtherDataType;

The state is stored rather haphazardly in either the Log record or the Info record depending on if it's ever going to be logged.  The Log value is what ends up being sent onward to the logging framework, so by default all of it's fields are logged.  The $pending_requests field can't be logging in any reasonable form and never really has any need to be logged so it's stored in the parent ::Info record.

Robin an I discussed creating a new attribute to support this notion of data for use by the logging framework.  If we make a &log attribute, that could transmit the intent of the field to the logging framework.  Here's an example of how this would look...

type Info: record {
	uri: string &log;
	host: string &log;

	pending_requests: SomeOtherDataType;

Although that attribute is annoying use case specific, I think it really makes for a much cleaner interface for creating these records that are meant for carrying data forward to the point of logging considering that in many cases there is other data that needs carried forward but is never logged (like pending_requests).  I'll give some examples of the two styles in use now..

Existing style..
active_http_session$log$uri = unescaped_URI;

New style...
active_http_session$uri = unescaped_URI;

Those are sort of silly examples but I wanted to show them to point out how often the $log$ fragment is reused, but it really isn't anything but syntactical noise that shouldn't really be there.  I think that the &log attribute would make the interfaces to these scripts quite a bit more palatable and enjoyable to use.



Seth Hall
International Computer Science Institute
(Bro) because everyone has a network

More information about the bro-dev mailing list