This is pretty basic and will generate logs for each individual test - drilling them down like this let's me help get at particular parts being executed like the date or structured data. I'll eventually make a helper to collate and display the data...
The profiling has shown that wildcard regexes and split based regexes are the biggest causes of inefficient code - however for some such as date parsing I can't think of a better way of handling it at this point in time.
Initial profiling of the code is showing that this regex based split is taking more than it's fair share of time. As a side penalty this could cause issues with messages having > 1 spaces as delimitered (although that's RFC violating).
I am somewhat divided by this commit, although it preserves all data it parses, it ends up making a object that's huge and too full of redundancy. I may end up "replacing" all of SDDATA with our parsed signed block instead of this.
Like the previous, signed block commit many of the same things apply: we don't touch and of the crypto apart from attempting to take it out from it's base64 state.
At this stage, supporting the validation of messages in terms of checksum and signature matching is not feasible because of the requirement to comply with RFC 4880. Since we at least give back buffer objects, end users can handle that themselves a little easier.
This commit brings in structured data support for RFC5424 and, more importantly, a much cleaner producer removing a lot of silly code. We also accept all fields that are possible to be filled in, and default appropriately when they are empty. In addition to this, the BSD style tests have been rewritten to be more inline with the RFC.
Instead of being regex based, we're stricter against the data, and also enable parsing structured data for RFC5424 messages along with supplying more metadata where possible. And no, this couldn't have been done in anything less than a single commit.