The (maybe only) good thing about there being no reference implementation is that we get feedback on the protocol itself and not the characteristics of a particular implementation.
In this first phase, we are providing tools to ease independent implementation. We think it would be a sign of health that the specs are (become) good enough to create interoperable implementations from. We will make our plans known as they develop. We are doing more with the core protocol next.
One thing I sorely missed when working with FAST was an official and comprehensive test suite. A wide set of templates and encoded files to exercise all the nooks and crannies of the spec would have been very useful.
It looks like blink has far fewer special cases so the need for an official test suite might not be as great. Might be something worth considering anyway.
agreed, a test suite will be essential for implementors. I'd be very interested to hear you thoughts on this. Please mail me if you have interest.
Rolf
Good point. Is it possible to create an unambiguous protocol specification that scales to more complex interactions? If so, and if you know how, I guess you would need a different specification language to get expressiveness? Blink has an extensible schema but that won't cut it. Anyhow, we have so far not even tried to do what you want but we hope that there is nothing in Blink that puts limitations on doing that separately. There is a lot more that we don't try to do in the protocol core.
Wire format - performance. Language describing the format - author friendliness compared to more verbose formats. We are going to release specs for an XML schema format and translations to and from the Blink format. The XML format can be used for mappings to and from "external" schemas. Should we do a JSON schema format?
To support schema evolution. Of course it's up to you to write code that can actually handle missing fields, but once you have a required field in a message, you can never remove it.
From the docs:
"You should be very careful about marking fields as required. If at some point you wish to stop writing or sending a required field, it will be problematic to change the field to an optional field – old readers will consider messages without this field to be incomplete and may reject or drop them unintentionally. You should consider writing application-specific custom validation routines for your buffers instead. Some engineers at Google have come to the conclusion that using required does more harm than good; they prefer to use only optional and repeated. However, this view is not universal."
good question; I usually declare fields optional for the reason described in the reply above. I just re-ran the test with all fields declared as "required". It ran ~2% faster.
