# README
simplebuffer
For simple applications it makes no sense to have complicated things added to them. This library aims to solve two problems in one: A binary encoding with a decoder that avoids copying and not using reflect but not making new data types difficult to add or new messages to string together. Something fast but simple and easy to extend and recompose.
Using a slice of a specific serializer type, with an interface that does the usual things required of a serializer, mainly, to produce a serialized representation of its contents, can be strung together in an arbitrary order and do not run until you generate the message container, and when received do not incur processing cost until the value is actually accessed, which can help ensure failure conditions are more rapidly responded to - only as many fields are needed to determine such a condition are required to be decoded in order to respond appropriately, whereas a standard serialization codec will decode everything anyway before you even see it.
This library is inspired by Flatbuffers, but its terrible support of Go and the use of complicated tools and syntaxes and generators, when I already understand interfaces and slices and before there is a version 1 it is easy to just ad-hoc write new types. The design is such that also when you use it, each interface implementation is a unit of compilation, and not any of the implementations present that you haven't imported.
In most cases, there is already a fast binary encoding scheme for almost any given data type implemented by servers already existing, usually fast, this allows also the arbitrary change of the content of messages for specific purposes without a performance hit from reflection. It is up to the user of the library to take care of message versioning and the simplest way would be to centralise the definitions of the magics. The encoders can be made zero-copy at the option of the implementor, the performance cost of copying is still less than reflection anyway, but the option is open for the future.
This is not really so much of a library as a pattern of construction with modular importable boilerplate. The goal is maximum performance especially latency in tasks that may not require complete decoding to determine a response.
For example, in the Bitses
implementation, it has an array of
packed binary encoded 32 bit integers. It unpacks them into a map when you
run the Decode
method, but doesn't generate the int32 value, and
subslicing usually will not copy the bytes, only create a new slice reference.
There is also a header containing a service advertisment for the controller
, it can be decoded with only knowing this part of the message at all, and
its component parts also subslice to the returned values so they are
basically zero copy, probably the conversion to int32 could be an unsafe type
conversion, or generate the string representation without intermediate int32
representation.
Go is a language that encourages creative repurposing of its syntax to many
other things than what was intended, and the use of closures, first class
functions and parser/generators stringing these calls enables metaprogramming
, yet without imposing complicated new syntax or feeling excessively clunky
(once you get over the func
:) )