My reasons for wanting to finalize the specification now

[surfskidude]

We implemented a UBJSON encoder/decoder, based on the current draft, for testing the protocol as a method of encoding/decoding M2M (Machine to Machine) communication. M2M is part of "Internet of Things" (IoT).

The reason we looked at UBJSON as an alternative to JSON is that it enables easy encoding of binary data. Also, our UBJSON implementation is much smaller than our JSON implementation. A small C implementation is required since the code will go into small microcontrollers with extremely limited memory. For us, the more compact UBJSON format was not as important.

I have briefly looked at the new suggested features listed on this forum and my concern is that most of these features, if accepted, will make the specification much more complicated. A more complicated specification leads to a larger code base when implementing the specification.

JSON and UBJSON have many use cases and we are probably looking at it from a very specific case. I have uploaded a draft version of a document that describes how UBJSON can be used for realtime M2M communication. The draft can be downloaded from: https://realtimelogic.info/tmp/JSON-and-UBJSON-encoding-and-decoding-in-C.pdf

My concern is that there will always be developers with unique use cases who will want to add "new features". By making the current UBJSON version final, UBJSON should get widespread usage as the specification is adequate or "good enough" for mainstream usage.

Let's keep it simple and practical.

[kxepal]

@surfskidude Current UBJSON version cannot be final since it has some flaws with handling optimized containers. This feature is important to significantly reduce the data size, even better then gzip/snappy additional encoding by removing repeatable service information about the data. You should know, that this is very painful moment for JSON and as for me this is the last blocking bit for the final release.

I agree that format should be simple and practical, but as you know JSON is also very simple and practical, and it's also "good enough"...until some moment, so we see a lot of attempts to fix it, but none cannot fix the JSON itself since this will "break the Internet" (c).

I agree that UBJSON stays in beta for too long and have to be already released yesterday. However, for this time we have got very useful feedback about current state of things and have a chance to fix them before it will be too late for sorry.

[ghost]

@surfskidude I echo @kxepal motivation to get the spec done, but I would point out that if we had stopped and announced "1.0" when I first started getting pressure to do this (year 1) the spec would be almost completely useless and no one would adopt it.

The strides we have made in the last 2 years have been significant -- I want to be really clear on that. Minor complexity increase with maximal performance benefits.

Alex is right that there is one remaining feature to be settled on, the repeatability of headers or 'mini schemas' - the data size shrinkage in typical use cases can be as high as 75% percent with NO compression algorithm in use... it is non trivial.

You are right that complexity to support it will be there, but if you are working on an internal implementation for use inside your own microcontrollers, I think it is reasonable to implement some subset of the spec that doesn't include this support (if you don't need it) and just add support for it later if you find a use-case where it is a huge win.

In summary - we are close, I feel your pain and my only goal has ever been to deliver a solid spec that people can use in effective ways while maintaing compatibility with JSON and I think we have done that (Against many odds).

I will keep moving discussions forward to get the spec closed out because as badly as you want 1.0 to happen, I guarantee that I want it 10x more -- we've been working on this a long time :)

[ghost]

Closing issue, but I want to let @surfskidude know that his concerns and desires are certainly understood by the team.