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.