[ANN] clj-cbor - Concise Binary Object Representation

292 views
Skip to first unread message

Gregory Look

unread,
Dec 28, 2016, 11:34:36 PM12/28/16
to Clojure

mvxcvi/clj-cbor is a native Clojure implementation of the Concise Binary Object Representation format specified in RFC 7049.


CBOR is a binary encoding with the goal of small code size, compact messages, and extensibility without the need for version negotiation. This makes it a good alternative to EDN for storing and transmitting Clojure data in a more compact form.

I've been itching to write this library since first reading through the CBOR spec, which is clear and well thought out. This is a native implementation and the library has no dependencies other than Clojure itself, and the current code is 100% covered by tests. I wanted to write this over using one of the existing two or three libraries because they were either based on Jackson, wrapped a Java lib and required interop, were insufficiently flexible with adding new type extensions, or some combination of the three.

clj-cbor uses a read- and write-handler approach similar to the ones in EDN and Transit, so type extension is simple. The library uses this same mechanism to provide default support for common types like Dates, Instants, Patterns, UUIDs, URIs, BigIntegers, BigDecimals, Ratios, Keywords, Symbols, TaggedLiterals, and sets.

John Schmidt

unread,
Jan 2, 2017, 5:02:47 AM1/2/17
to Clojure
Looks neat! What would you say are the pros and cons of CBOR compared to Fressian, which seems to have similar goals?

Gregory Look

unread,
Jan 3, 2017, 7:47:47 PM1/3/17
to clo...@googlegroups.com
A lot of the design goals are similar between CBOR and Fressian - namely, providing a compact but extensible binary serialization format.

Fressian is a bit more Clojure-specific, given that it has things like sets, keywords, and symbols as first-class data types. Fressian is also concerned with performance by having caching as an explicit part of the design, which moves it more towards a protocol than solely a data format. One effect of this is that Fressian codec implementations must be more complex to handle this part of the spec properly.

By contrast, CBOR's goal is both compact representation and implementation, so the format is deliberately simple, with extensions left to the implementer. As an example, there are some registered tags for caching values within an object, which could be used to implement caching similar to that in Fressian.

One of the big pros in CBOR's favor is that it's an open standard, so interoperability is better than language-specific formats. To the best of my knowledge, Fressian isn't really promoted for use as a format independent of Datomic, and there are few libraries available for working with it off the JVM that I can find. CBOR has several libraries available in a variety of languages, so users don't need to worry as much about lock-in or inability to use their data with the tools of their choice.

Greg


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/RvCjGi1cF7A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Dirk Kutscher

unread,
Jan 17, 2017, 11:00:12 AM1/17/17
to Clojure
Great -- I was looking for that!

Dirk


On Thursday, December 29, 2016 at 5:34:36 AM UTC+1, Gregory Look wrote:
Reply all
Reply to author
Forward
0 new messages