This is sort of an extension on the previous email, but sort of a different topic at the same time.
In the active_conns thread, Robin mentioned the idea of extending the connection record to include these state tracking records directly within it. At first I was going to say that I didn't like the idea because it made state tracking less "regular" in that the cases where state not related to a connection is being tracked, the fall back would be to use a global table with some index.
As I thought about it more and wrote some code for how it would look to use it, I realized that I liked the idea more and more. For starters, non-connection oriented state tracking is a bit of an exception in many cases and secondly, there is quite a bit less indexing into tables that needs to be done, and lastly, the syntax is much cleaner and nicer to look at and use. Here are some examples:
Currently...
HTTP::active_conns[c$id]$log$uri;
By extending the connection record...
c$http$uri;
Using Robin's code to extend records is easy and fairly clean looking too...
redef record connection += {
http::Info;
};
This has the additional benefit of providing a very easy way for script writers to find out if some certain functionality is available with the field existence testing operator (?$) by checking to see if the http structure is available (for example) by doing c?$http. It's much clearer in it's intent than some of the existing hacks like using @ifdef to find if some variable exists.
If we combine this proposal with the &log attribute proposal, I think we can make some very clean interfaces for interacting with data and making it really easy to understand and expand on the scripts that we ship.
Thoughts?
.Seth