I'm the author of dynamic-object
<https://github.com/rschmitt/dynamic-object>, an open source library that
makes Clojure's data modeling power available to Java programmers. This
includes features like serialization and deserialization. I'll copy this
small usage example from the README to give you a sense of how it works:
public interface Album extends DynamicObject<Album> {
@Key(":artist") String getArtist();
@Key(":album") String getAlbum();
@Key(":tracks") int getTracks();
@Key(":year") int getYear();
}
String edn = "{:artist \"Meshuggah\", :album \"Chaosphere\", :tracks 8, :year
1998}";Album album = DynamicObject.deserialize(edn, Album.class);
album.getArtist(); // => "Meshuggah"
dynamic-object has always been opinionated about using Edn as the primary
data language on the wire, for a number of reasons. For a long time, I also
thought about adding Fressian support to dynamic-object, and I've recently
done so on an experimental basis. (It looks like this
<https://github.com/rschmitt/dynamic-object/blob/440ecd2f385d1cec80496ba7007bd0755023b19c/src/test/java/com/github/rschmitt/dynamicobject/FressianTest.java>.)
Some time after I initially released dynamic-object, Transit was also
released, with support for various encodings (JSON, JSON-Verbose,
MessagePack).
In working (to different extents) with these data languages, I've had some
apprehensions about all of them.
- There is a lack of tooling available for Edn, such as validators and
pretty-printers. I spent a while looking for an Edn equivalent of python
-mjson.tool and never found one. Clojure's built-in pprint function does
not work out-of-the-box to pretty print arbitrary values, and also appears
to handle some data structures, such as records, incorrectly. (pprint omits
reader tags when printing records.) pprint's underlying implementation,
cl-format, is extremely powerful and could almost certainly be used to
build a validating Edn pretty-printer, but it would have an unacceptably
long startup time.
- There is a lack of high-quality Edn implementations for different
languages. Because the Edn spec is not very formal or complete, there seems
to be some uncertainty regarding what constitutes an Edn implementation in
the first place. For instance, clojure.edn parses the Ratio type as a
builtin, even though it is mentioned nowhere in the spec. (Issue
<https://github.com/edn-format/edn/issues/64>.) There are also oddities
such as the recommended C++ implementation
<https://github.com/shaunxcode/edn-cpp> describing itself as
"experimental."
- Fressian's reference Java implementation is almost totally
undocumented. This is a problem, because I'm writing a library that targets
Java developers; they won't be going through the Clojure bindings (which
are decently documented). Fressian's source code is outstanding, but it's
still not documentation.
- Due to the lack of documentation, it's not clear which parts of
Fressian are actually stable. Stuart Halloway's data.fressian talk included
some parentheticals about the extension points being subject to change,
which so far they haven't, but that might only be because of the following
point...
- Fressian does not seem to have gotten any attention since the initial
launch. People have submitted GitHub issues
<https://github.com/Datomic/fressian/issues>, including one surprisingly
high-quality bug report, but they have all been ignored. The JIRA is mostly
tumbleweeds.
- The Clojure bindings for Fressian, namely data.fressian, are
essentially incomplete. With the exception of maps, Clojure collection
types do not round trip, and in at least one case (vectors) that is because
of a blocking issue <http://dev.clojure.org/jira/browse/DFRS-1> in the
underlying Fressian implementation.
- There are no documented best practices for the use of Fressian or some
of its more advanced features like chunking. It is not clear how to read
and write Fressian in a way that facilitates (for instance) ranged reads
from the middle of a resource. It is not clear when checksums should be
used and how they should be validated. It is not clear whether tags should
be namespaced, or how. The only namespaced tag in data.fressian is for
IRecord; none of the other type tags are namespaced. It's not clear whether
this is due to bugwards compatibility.
- Transit is advertised
<https://github.com/cognitect/transit-format#implementations> as a
work-in-progress. This is the main reason I haven't seriously considered
adding Transit support to dynamic-object.
- However, what happens when Transit is stabilized (if that ever
happens)? Since Transit offers a msgpack encoding, will Fressian then be
irrelevant (except for legacy use cases)? There's a FUD aspect here--I like
Fressian and I want dynamic-object to support it, but I don't want to back
the wrong pony and end up having to support HD-DVD and Betamax for all time
(so to speak).
- Can these formats be unified? Can Edn and Fressian encodings for
Transit be offered? Would that even accomplish anything?
I realize that none of these data languages will have the same extent of
support and tooling as JSON or XML, but I want to ensure that
dynamic-object's supported data languages all have attentive stewardship
and bright futures. It's distressing that a lot of the issues with Edn and
Fressian have not gotten much traction. Are these languages still actively
being supported and fostered? If so, how much development activity is
taking place on internal forks? Are any public updates planned for these
languages any time soon?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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 the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
