# \[ANN\] Orsetto: structured data interchange languages (version 1.0) **URL:** \ **Category:** Community\ **Tags:** json, serialization, cbor, orsetto, announce\ **Created:** [June 14, 2019, 1:35am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920 "2019-06-14T01:35:16Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [June 14, 2019, 1:35am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/1 "2019-06-14T01:35:16Z")
I am pleased to announce the release of version 1.0 of my [Orsetto](https://bitbucket.org/jhw/orsetto) project. As I wrote in the **README** file about it: > Orsetto is a standalone library comprising a core toolkit… > > - Core functional data structures and processes. > - Unicode transport, normalization, parsing and formatting. > - General purpose packet format encoder-decoder processes. > > …used to implement streaming parsers and formatters for a useful variety of > structured data interchange languages… In this first release 1.0, the major featured languages are only **JSON** and **CBOR** , but my hope is to expand this list to include a variety of other useful languages in the 1.x release series. Moreover, it’s only non-build and non-test dependency is the OCaml distribution itself. The programming interfaces are fairly low-level, and sufficiently different from other implementations that I feel **Orsetto** may be a welcome alternative to other serialization libraries. **Orsetto** is [now available](https://opam.ocaml.org/packages/orsetto/) at the community OPAM repository, and preview releases of forthcoming versions will continue to be available at my personal repository in Bitbucket, which you can use in the conventional way: > opam repository add jhwoodyatt git+https://bitbucket.org/jhw/opam-personal.git I have been hacking on various personal projects in OCaml for about seventeen years now, and **Orsetto** represents the portions of all that I find myself regularly reusing. I’m now promising the OCaml community to be as responsive to issues filed on [the Issue tracker](https://bitbucket.org/jhw/orsetto/issues) as my day job allows, and I welcome contributions and criticisms. _p.s. Now that I’m no longer a Googler, I may now be free to work on some of the features that I deliberately avoided, in compliance with my employment contract while I was employed there._ ---
**Author:** ![darrenldl](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/darrenldl/32/291_2.png) [@darrenldl](https://discuss.ocaml.org/u/darrenldl)\ **Post date:** [June 14, 2019, 3:25pm UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/2 "2019-06-14T15:25:01Z")
Is the project distributed under any license? ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [June 14, 2019, 5:53pm UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/3 "2019-06-14T17:53:45Z")
The BSD 2-clause license is default. If you would like another license, I’m open to negotiation. ---
**Author:** ![darrenldl](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/darrenldl/32/291_2.png) [@darrenldl](https://discuss.ocaml.org/u/darrenldl)\ **Post date:** [June 15, 2019, 12:44am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/4 "2019-06-15T00:44:11Z")
Aha, thanks! BSD 2-clause is fine for me, and I am interested in contributing in future when I’m free. I was asking as I can’t seem to find a license section in the README or a LICENSE file. **EDIT:** Are you open to the option of migrating to dune? ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [June 15, 2019, 6:43am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/5 "2019-06-15T06:43:42Z")
p1. Yeah, I’ll add an explicit **LICENSE** file in the unstable branch. All the source files have BSD 2-clause license headers accompanying the copyright declaration. p2. When I started this project years and years ago, before even Dune’s predecessor jbuilder was available, it used my personal OMake library, which I also released simultaneously (under a BSD 2-clause license as well) as the [Conjury](https://opam.ocaml.org/packages/conjury) package. It has some features I like that Dune still lacks. Adding an optional Dune build would be something I would consider, but only once I understand how to make it do what I’m able to do with Conjury. In particular, I very much like that Orsetto is one OPAM package that installs with _ocamlfind_ an “orsetto” package with each of the various libraries in the framework offered as a subpackage. I don’t currently understand how to do that with Dune. ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [June 24, 2019, 2:30am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/6 "2019-06-24T02:30:29Z")
A few days ago I ran the Orsetto JSON parser through nst@github’s JSON test suite and it revealed a couple of problems. Fixes are already in the branch for the 1.0.1 release I plan to make at the end of the month. ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [July 4, 2019, 7:52pm UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/7 "2019-07-04T19:52:47Z")
The 1.0.1 release is in the merge queue for the community OPAM repository now. ---
**Author:** ![avsm](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/avsm/32/6_2.png) [@avsm](https://discuss.ocaml.org/u/avsm)\ **Post date:** [July 8, 2019, 11:01am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/8 "2019-07-08T11:01:14Z")
> [@jhw](#): > > It has some features I like that Dune still lacks. What sort of features do you need that are missing in Dune? Do feel free to create issues on the Dune GitHub issue tracker with use-cases that would help you. ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [July 9, 2019, 4:59am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/9 "2019-07-09T04:59:10Z")
> [@avsm](#): > > What sort of features do you need that are missing in Dune? Said it’s missing features I would _like_, not that I _need_. **Dune** is billed as an “opinionated build system” that is “designed for Reason and OCaml projects _only_” (emphasis mine). I don’t feel the need to litigate over what amount to my differences of opinion except to say that a reason I like **OMake** is that it’s not trying to be a build system for any particular language tool chain. It just wants to be— and I think it succeeds admirably at being— a good replacement for the venerable `make(1)`, and I _really_ like that about it. That said, I’m not opposed to offering Dune project files for Orsetto, provided I can figure out how to make it a seemless replacement for OMake+Conjury. It might already be capable of doing that— I just don’t know how to use it, and I haven’t tried to learn it because— well, um— the few things that Dune actually does that OMake+Conjury cannot yet do are not terribly difficult to fix, and I’ll get around to it when the need becomes pressing. As I mentioned before, one of the things I don’t yet know how to do with Dune is to deliver a single _opam_ package comprising multiple _ocamlfind_ packages, each with varying interdependencies and external dependencies of their own. It appears from my cursory evaluation that this isn’t the usual mode of delivering libraries with Dune. Instead the pattern I frequently see is that each internal library is delivered as a separate opam package built from the same workspace. That model really sets my teeth on edge, and I’m resisting it. I don’t know whether that’s one of the “opinions” inherent in the Dune build system, or if it really represents a problem that should be filed in the issue tracker. I searched for it in the issue tracker, and I didn’t see it, which leads me to believe it’s the former and not the latter. As a side note, it’s not clear to me why anybody should care that Orsetto doesn’t have a Dune build system. Isn’t that supposed to be one of the nice features of opam? You don’t have to care what particular build system a package is using— you only care that it installs things into the OPAM switch where it can be referenced by other packages. ---
**Author:** ![samoht](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/samoht/32/81_2.png) [@samoht](https://discuss.ocaml.org/u/samoht)\ **Post date:** [July 9, 2019, 7:23am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/10 "2019-07-09T07:23:38Z")
> [@jhw](#): > > As I mentioned before, one of the things I don’t yet know how to do with Dune is to deliver a single _opam_ package comprising multiple _ocamlfind_ packages, each with varying interdependencies and external dependencies of their own. It appears from my cursory evaluation that this isn’t the usual mode of delivering libraries with Dune. I guess you are looking for something like that: [https://dune.readthedocs.io/en/latest/installation.html?highlight=public\_name#libraries](https://dune.readthedocs.io/en/latest/installation.html?highlight=public_name#libraries) If you name your libraries `orsetto.foo` they will be installed as an ocamlfind sub-library for orsetto. And you can use either local or external libraries in the `libraries` stanza so it’s easy to have complex inter-dependencies. You can also check [GitHub - mjambon/dune-starter: Simple template for midsize OCaml project](https://github.com/mjambon/dune-starter) for a relatively complex template for dune projects. ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [July 9, 2019, 2:39pm UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/11 "2019-07-09T14:39:39Z")
> [@samoht](#): > > I guess you are looking for something like […] Ah, yes— so that’s how **Dune** does something _like_ what I want. Except I’m also not an admirer of the `-no-alias-deps` compiler flag, and I suspect that’s in the category of “difference of opinion” not a lack of a feature. Although, [issue #1819](https://github.com/ocaml/dune/issues/1819) is relevant here. So, it looks like all the features I would _need_ are available in **Dune** , but the question remains: why would anybody care which build systems I’m using? It would be a fair bit of work to develop a parallel build system for Orsetto that uses **Dune** (mainly because of the code generator in the Unicode library), and I’m not understanding what problem it would solve. ---
**Author:** ![rgrinberg](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/rgrinberg/32/40_2.png) [@rgrinberg](https://discuss.ocaml.org/u/rgrinberg)\ **Post date:** [July 9, 2019, 4:28pm UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/12 "2019-07-09T16:28:39Z")
> [@jhw](#): > > Ah, yes— so that’s how **Dune** does something _like_ what I want. Except I’m also not an admirer of the `-no-alias-deps` compiler flag, and I suspect that’s in the category of “difference of opinion” not a lack of a feature. Although, [issue #1819](https://github.com/ocaml/dune/issues/1819) is relevant here. If you don’t like `-no-alias-deps`, you may use the `(wrapped false)` mode to disable it. I’m not in any way trying to convince you to use dune, just making a remark 🙂 ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [July 10, 2019, 5:51am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/13 "2019-07-10T05:51:35Z")
> [@rgrinberg](#): > > …use the `(wrapped false)` mode to disable it. Oh! Okay, that’s cool. So, I guess the TL;DR here is that as soon as I understand the nature of the problem that would be solved by adding support for the **Dune** build system to Orsetto, I can file an issue to cover it and give it all due consideration. ---
**Author:** ![rgrinberg](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/rgrinberg/32/40_2.png) [@rgrinberg](https://discuss.ocaml.org/u/rgrinberg)\ **Post date:** [July 10, 2019, 4:56pm UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/14 "2019-07-10T16:56:53Z")
> [@jhw](#): > > As a side note, it’s not clear to me why anybody should care that Orsetto doesn’t have a Dune build system. Isn’t that supposed to be one of the nice features of opam? You don’t have to care what particular build system a package is using— you only care that it installs things into the OPAM switch where it can be referenced by other packages. This is a feature that comes with disadvantages. Some people are working on a dune only package manager and it seems to have some compelling advantages: - The ability to edit dependencies without pins - Much faster build times with composed projects - Free cross compilation Having dune files in your projects makes them usable in such a setup. ---
**Author:** ![jhw](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jhw/32/1639_2.png) [@jhw](https://discuss.ocaml.org/u/jhw)\ **Post date:** [July 10, 2019, 5:30pm UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/15 "2019-07-10T17:30:34Z")
> [@rgrinberg](#): > > …it seems to have some compelling advantages: […] All of those are reasons to add Bazel as a supported build system. And Bazel has the advantage of being a mature system, with support for a wide variety of programming languages, not just OCaml, and which I use in my day job already. Not sure how this forthcoming Dune system will be better than Bazel. Any pointers would be nice. ---
**Author:** ![rgrinberg](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/rgrinberg/32/40_2.png) [@rgrinberg](https://discuss.ocaml.org/u/rgrinberg)\ **Post date:** [July 11, 2019, 12:06am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/16 "2019-07-11T00:06:50Z")
Indeed that’s a good point. Bazel/Buck alone does not provide a full story because they’re too heavyweight for the average open source project. However, I realize that for companies with existing polyglot monorepos, they’re the only feasible option. I think there’s one crucial way in which dune is going to stay much better than Bazel/Buck and other OCaml build systems: it has the best rules for building OCaml code by far. As far as I know, it’s the only system that has all of: - Correctly uses ppx’s by building drivers. - Allows transparent definition of ppx rewriters with runtime dependencies - Understands `-opaque` - Protects the user from toplevel name collisions for wrapped libraries and executables - Supports virtual libraries (the linking hack generalized) - Transparent support for inline tests - Support many external tools like jsoo, merlin, odoc. I would like to share these benefits with users of Bazel/Buck, but it’s still an open question on how to best accomplish that. ---
**Author:** ![jeremiedimino](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jeremiedimino/32/699_2.png) [@jeremiedimino](https://discuss.ocaml.org/u/jeremiedimino)\ **Post date:** [July 16, 2019, 3:08pm UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/17 "2019-07-16T15:08:35Z")
> [@rgrinberg](#): > > I would like to share these benefits with users of Bazel/Buck, but it’s still an open question on how to best accomplish that. Does Bazel/Buck support plugins? If yes and depending on how powerful the internal APIs are, that shouldn’t be very hard to do. ---
**Author:** ![rgrinberg](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/rgrinberg/32/40_2.png) [@rgrinberg](https://discuss.ocaml.org/u/rgrinberg)\ **Post date:** [July 17, 2019, 10:02am UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/18 "2019-07-17T10:02:58Z")
I don’t think Bazel supports plugins. The only way to add support would be to generate `BUILD` files from dune. This is basically the same as generating makefiles. However, I think that such BUILD don’t really need to be portable and will be generated by dune whenever the repo is cloned. The only key thing here is to make sure that the rules for ocamldep are encoded in the `BUILD` file. This is so that we don’t need to re-run dune everytime a module is changed. ---
**Author:** ![jeremiedimino](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jeremiedimino/32/699_2.png) [@jeremiedimino](https://discuss.ocaml.org/u/jeremiedimino)\ **Post date:** [July 17, 2019, 12:39pm UTC](https://discuss.ocaml.org/t/ann-orsetto-structured-data-interchange-languages-version-1-0/3920/19 "2019-07-17T12:39:09Z")
I see, Things such as `(:include ...)` or `%{read:...}` might be a bit annoying to handle as well.