- You've chosen a novel schema and message grammar. Did you consider XML for the schema? We think our grammar is more human friendly. We plan to add an XML schema format and conversion tools from the Blink grammar to and from XML, as a bridge to other XML sources. It makes sense to use other repository formats as a source for schemas, as the Blink schema grammar is not suited for a large amount of ancillary information such as structured documentation.
- How does Blink compare to say ASN.1 or Google Protocol Buffers? There is a blog entry comparing Blink to Google Protocol Buffers. It is on our todo list to make comparisons to other protocols. We also welcome independent review.
- Why isn't Blink built on top of ASN.1? Blink is designed to be simple and self sufficient. It should be straightforward to map Blink messages onto ASN.1 PER and get characteristics similar to the Blink Compact and Native formats.
- Why does the core specification include a wire format? The beta1 release of the core specification included a continuation-bit encoded variable-length format. The beta2 release switched the encoding to use a more processing efficient variable-length format that is called Compact while introducing a second binary format called Native. The idea is to let Blink be wire-format independent but to cover as many needs as possible with as few formats as possible, to avoid fragmentated use. We have so far included the compact format in the core specification to make the text concise and hopefully easier to understand in a single reading session.
- Why two binary formats? To cover the spectrum of different requirements on coding efficiency (size) versus processing overhead (speed) that we see. Within a machine and within a data center, the overhead in processing the compact format in software can become the messaging performance bottleneck. The native format has a significantly different size vs software speed profile to make it a distinctly better format for some workflows.
- Why have you put in non-core types into the type system? One idea would be to layer the type system and make the derived types (date, boolean, enumeration, decimal, etc) best practice or default interpretations of those constructs. We have chosen a pragmatic approach based on empirical experience when selecting the additional types. Enumerations are very common in many protocols. The time, date, and decimal types are abundant in financial protocols and important to represent efficiently. Leaving these types out would add clutter and layering to user schemas. This is obviously an act of balance, but in the aim to make Blink complete and fit for purpose we believe the types we have put in are necessary. We have had feedback saying the type system should maybe be expanded further to include a bitmap or multi-value enumeration.
- How is Blink benchmarked? So far, we do some of the low level, micro benchmarking using a static C implementation. The C implementation is used as a performance reference point for a rich implementation that is part of Ordo. The rich implementation is dynamic, allowing build time code generation for schemas known at build time, and reflection access to messages that are defined on the fly. This implementation makes us able to say that a feature rich codec working in a feature rich environment does not have to be bloated and slow. We use this implementation to build real applications and do benchmarking of real workflows as we think there is limited value in studying the performance of a codec running on its own.
Copyright ©, 2012-2013, Pantor Engineering AB. All Rights Reserved