@michielbdejong Hi Michiel, I interpret the "JSON" (protocol) can be considered deprecated right now. That was the protocol I was using for the java ledger (https://github.com/earizon/java-vertx-ledger/tree/master/src/main/java/com/everis/everledger/handlers) -that actually is not java but kotlin using the java-ilp-core package -.
Is there any code to check how the new binary protocol is being used in NodeJS?. I'm thinking something similar to the five-bells-ledger/tests I used to develop the java/kotlin ledger.
My intution says that porting from JSON to OER must be a matter of "re-encoding" the messages, so it must not be really difficult.
Restarting a old discussion. I'm not convinced that using and Interface for value-objects is a good idea. Providing a POJO with a constructor and private final fields with setters will translate missing parameter errors from runtime ( MyClass myInstance = WhatEver.builder().setParam1().setParam2 ...build() ) to compile time ( MyClass myInstance = new MyClass(param1, param2, ...) ) , following the fail-fast design (https://en.wikipedia.org/wiki/Fail-fast), one the few "absolute true" in software design. The only real scenario where Interfaces are suitable IMHO is that in which the value-object is "big" and so different strategies for storing the data can be applied in different context (embedded, servers, clusters,...).
First results on Google - https://www.google.com/search?&q=interface++%22value+object%22 - looks to favor NOT to use Interfaces for value objects :
https://stackoverflow.com/questions/25457028/designing-value-object-by-interface
https://softwareengineering.stackexchange.com/questions/185636/should-i-create-interfaces-for-data-transfer-objects
of course interfaces can still be very useful for value-object for the purpose of "tagging" the classes/instances as having some sort of property not directly related to value storage, but to the orthogonal properties like Printable, Serializable, Orderable, Comparable, TaintedInput, UntaintedOutput, ... )