Add custom serialization support

[ptaoussanis]

Thanks to James Reeves for this suggestion:

(thaw bytes {:readers {Vector3D read-vector} :writers {Vector3D write-vector})

It might result in a prefix for the data like 80 \V \e \c \t \o \r \3 \D \

(defn read-vector [^DataInputStream s]
  (Vector3D. (.readDouble s) (.readDouble s) (.readDouble s)))

(defn write-vector [^DataOutputStream s ^Vector3D v]
   (.writeDouble s (.getX v))
   (.writeDouble s (.getY v))
   (.writeDouble s (.getZ v)))

[ptaoussanis]

Update: an alternative would be to reserve some part of the type-id space (-128 to -1 say) for custom types, and suggest that folks extend their custom types to the current Freezable protocol.

Then thaw-from-stream could be made extensible - perhaps with a {<custom-id> <fn-of-stream>} map passable to thaw/thaw-from-stream.

[ptaoussanis]

As of v2.1.0 currently on the dev branch:

(defrecord MyType [data])

(nippy/extend-freeze MyType 1 ; A unique type id ∈[1, 128]
  [x data-output-steam]
  (.writeUTF data-output-stream (:data x)))

(nippy/extend-thaw 1 ; Same type id
  [data-input-stream]
  (->MyType (.readUTF data-input-stream)))

(nippy/thaw (nippy/freeze (->MyType "Joe"))) => #taoensso.nippy.MyType{:data "Joe"}

This approach makes some tradeoffs.

PROS

• Easy extension API. Automatically handles all the nasty business of writing type ids, stream type hinting, etc.
• Custom types get near-native-type performance. (Freeze speed is identical, thaw a little slower).

CONS

• No easy way to provide different readers/writers on an ad hoc basis as with a {:readers {Vector3D read-vector} :writers {Vector3D write-vector}) form.

Any other thoughts?