Re: A change to string encoding
On Tue, 2009-03-10 at 11:58 -0400, Steve Grubb wrote:
On Tuesday 10 March 2009 07:07:17 am Matthew Booth wrote:
> The problem with current string encoding is that it is parsable, but
> non-human readable.
There are times when it has things that would never be human readable.
Do you have an exhaustive list? Off the top of my head I can think of
the record which contains a struct sockaddr.
> URL encoding is just one way to achieve this, and has the
advantage of
> being widely implemented.
Inside the kernel?
No, I mean the format output by the audit daemon.
> I'm sure this has been considered before. Given that
it's a road I'm
> considering heading down, what were the reasons for not doing it?
Can you encode data structures in it? The kernel developer at the time wanted
something that was either already in the kernel or something that could be
implemented in a couple lines of code and something that works for any kind
of encoding that needed to be done. So, I think minimal amount of code and
maximum flexibility is what drove the decision.
Sounds like this falls in to the 'easy to produce' category. We also
need to consider how this data is consumed. I'll take this opportunity
to suggest again that a binary format produced by the kernel would be no
worse than a hex encoded binary format, and a whole lot easier for the
audit daemon to mangle into something usable on the output side.
Matt