Since my previous post on Filbert I have added a simple but functional BERT-RPC client which I have managed to test against native Erlang modules running on Ernie.
To make it easier for you to try it out I’ve uploaded the package to NuGet, which you can download from here, or run the simple NuGet command:
in the package manager console inside Visual Studio.
To try it out, please have a look at the examples available on the project’s wiki page (see below list) or take a look at the F# and C# example projects included as part of the solution.
Again, feedbacks and suggestions are very welcomed, and do let me know if you run into any problems or inconveniences whilst using Filbert and I’ll do my best to help you resolve them ASAP.
I spent the last couple of nights and put together a small BERT serializer for .Net called Filbert.
BERT (Binary ERlang Term) is a binary format based on Erlang’s binary serialization format (as used by erlang:term_to_binary/1) but supports a couple of complex types such as boolean, dictionary and time, in additional to the primitive types.
BERT and BERT-RPC was specified by GitHub’s cofound Tom Preston-Werner and bas been in production use at GitHub as part of their infrastructure allowing them to integrate Ruby and Erlang through the Ernie BERT-RPC server.
The encoding format for BERT is the same as Erlang’s external term format which you can read about in great detail here. It is not as highly optimized as something like protocol buffer but is very easy to understand and implement and does not require a separate contract definition file (the .proto file for protocol buffer) in order to be able to serialize a type.
How can I try it?
I have yet to put together a Nuget package for Filbert but will do so in the near future, in the mean time why not fork the project on GitHub and try it out for yourself?
I have included a simple F# and C# example project as part of the solution, and if it’s not clear then have a read of the tutorial page to help you get started.
I have ensured reasonable test coverage for both encoder and decoder but there are no doubt many edge cases which I haven’t considered and would really appreciate any feedback you have on how best I can improve the solution