So, the first thing I was looking at was the client-server code in JKstat. One of the things that's always irritated me about XML-RPC is it's obvious lack of a long data type. It doesn't seem to be bothered that the world is more than 32-bits. Sure, there are various vendor extensions (and I have to turn them on in the Apache XML-RPC implementation that I use) but the result is something that's horribly non-portable.
The other thing I've been looking at is the archive format used in KAR. I started out with simple
kstat -p
but that proved inadequate in that important data (metadata) was missing, so I developed a private format. This was better, but was a horrid hack.So, enter JSON. It turns out that it makes an excellent serialization format for kstats.
- Reusing a standard means there's less work for me to do.
- I can use the same code for KAR and the JKstat client-server mode.
- There are JSON bindings in almost all languages, so interoperability is easy to achieve.
- The format is a string, so no messing about with extensions to pass longs.
- For KAR, it's almost twice as quick to parse as my own hacked format.
As a result, the next versions of JKstat and KAR will support JSON as their archive and interchange format.
As an aside, this opens the door to wicked cool stuff.
1 comment:
Be careful with longs in JSON. If it's ever going to be processed by JavaScript, you only get 53 bits because JS uses IEEE doubles for all numbers.
Post a Comment