this.generalizedTimeFormatter = new DateTimeFormatterBuilder() .appendValue(ChronoField.YEAR, 4) .appendValue(ChronoField.MONTH_OF_YEAR, 2) .appendValue(ChronoField.DAY_OF_MONTH, 2) .appendValue(ChronoField.HOUR_OF_DAY, 2) .optionalStart() .appendValue(ChronoField.MINUTE_OF_HOUR, 2) .optionalStart() .appendValue(ChronoField.SECOND_OF_MINUTE, 2) .optionalStart() .appendFraction(ChronoField.MILLI_OF_SECOND, 3, 3, true) .optionalStart() .optionalEnd() //millis .optionalEnd() //seconds .optionalEnd() //minutes .optionalStart() .appendOffset("+HHmm", "Z") .parseDefaulting(ChronoField.OFFSET_SECONDS, 0) .toFormatter();
Some feedback - the rfc changes to address the time format problem has been accepted, so we know what to do for the codec. I already have a working implementation.
I also looked at how we could support sequences in oer, long story short i don't think it's doable because of the type erasure - we just don't know which oer type to deserialze. I'll implement the sequence of liquidity points directly in the liquidity curve quote codec, if we find a generic way we can come back and fix it.
@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.