search

ubjson / universal-binary-json

Community workspace for the Universal Binary JSON Specification.
115 stars 12 forks source link

Massive draft-related confusion / status #58

Closed Miosss closed 9 years ago

Miosss commented 9 years ago

Hello. Wow, I see that more people are confused with resources concerning UBJSON.

Having read both the ubjson.org version, and later the one contained in this repository (blast, so many questions occurred while reading!), I conclude that the most actual one is that on he website, am I right? If so... it would really help the standard, I think, to outline that fact. And I am not alone as I see in #42 And even if the website is the one and only resource - maybe it would be appropriate to write down in this repo, that those information are outdated/deprecated. And I do believe, that indication of draft version on the website would be helpful.

I am very fond of the UBJSON idea in general (coming from IT/telecom background) and I have seen proprietary hardware protocols that are very similar to ubj. It combines quite decent optimization / efficiency level (networking...) and simplicity of JSON (IT). Therefore I would love to see it organized and popularized shortly. For this to happen I believe more consistency is needed, as I described before. By the way - what is the target of this spec - RFC or something similar? And how close are you to publication? As for data-exchange format, I believe that specification should be as stable as possible, so I am far from urging anybody : )

Not so issue - related, but are you interested in C++ parser at the moment? Not sure yet, if it would be good to create wrapper over the C version or to create cpp optimized version (maybe with optional Boost suppport).

Hope to make some addition to the community : ) Cheers

Steve132 commented 9 years ago

So, I could be wrong about this, but I'm fairly certain the one on the website is always considered to be the 'current' draft.

However, I strongly agree with you that every draft document should ABSOLUTELY have the version number on it somewhere. I have no idea which revision the current spec is, and am mostly making it up as I go.

Not so issue - related, but are you interested in C++ parser at the moment? Not sure yet, if it would be good to create wrapper over the C version or to create cpp optimized version (maybe with optional Boost suppport).

I'm the maintainer of the C version. I don't see any reason you couldn't or shouldn't write a C++ wrapper of course, but I'm curious why you would want to? The C API gives you access to pretty much everything. Additionally, what features from boost would you want to use?

I'm not poo-pooing I'm mostly just trying to figure out what you want, because I'd be willing to help write such a wrapper if the need was compelling.

breese commented 9 years ago

@Steve132 An example is Boost.Serialization, where you can abstract the format (e.g. UBJSON, JSON, or MsgPack) into a polymorphic serialization archive, which means that the user can write his serialization code completely independent on the chosen format.

This is what I have done in my protoc project (the UBJSON implementation is not announced on the front-page because it is still at Draft 9, but the code is there.)

ghost commented 9 years ago

@Miosss sorry for the confusion - I take full responsibility for that.

http://ubjson.org is the formalized/edited/polished public representation of the spec.

GitHub Issues (where we are here) represents the current changes that are being discussed and if there is agreement, then we wait on me to ratify them into the official spec on the website. <-- The more defined the spec gets, the slower this process gets BY DESIGN. I intentionally increase the window of accepting changes to make sure they vet out without me causing massive churn. That said, there are a few changes here that we need to bottom out on before I ratify them, namely the massive discussion around the new container header definitions and the ability to repeat them anywhere inside a container. (coalescing #48, #50, #51 #57 all together... not a trivial task).

The goal is eventually an RFC. I think that is a likely goal for next year.

After that my only focus will be libraries and tooling for the next few years.

I'm closing this issue because I'm not sure a specific actionable item is going to come out of it, but if you did need me to change something specifically let me know and I'll re-open.