@michielbdejong I have a deploy in google for the Java virtual plugin, but it's unable to connect to connector.land. Either the credentials you forwarded are incorrect, or I'm assembling them incorrectly. Unfortunately, I won't have time to work on it till this weekend, however. If you can see anything in your server logs for the creds you supplied, let me know.
the peering has to be mutual, otherwise it doesn't work
I think this is the right link: https://bluejeans.com/795795755
I think I messed up the calendar invite / I accidentally set the date for next week, Adrian may not join
Outlook doesnt seem to like the invite.ics file either, has anyone else had that issue?
@jgallare and @andrew-g-za - not sure if the time zones got mixed up again for the java call, but we're on now if you want to join.
@adrianhopebailie - if you get a chance could you please take a look at interledger/rfcs#230, or see if you can raise its visibility? It may be semi-trivial, but i think it has a big impact on correctness.
@all Hi, I will not be able to assist to today's java call. Anyway I can summarize my work in Interledger has been centered around creating a link map to resync with current work. I think it can be useful to any others, it's available @ https://htmlpreview.github.io/?https://github.com/earizon/IT_notes/blob/master/Interledger/interledger_map.html
Juan Carlos is on vacation, but I ignore if he will connect remotely.
Regards!
Enrique
Juan Carlos is on vacation, but I ignore if he will connect remotely.
Regards!
Enrique
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();
:(
yuck
@adrianhopebailie yes, another thing I thought is interesting for the Java project is https://github.com/michielbdejong/ilp-frog - it means you only have to implement the http calls which we've already worked on during the Berlin workshop, and gives you access to five-bells-ledger, xrp-escrow, and any other ledger for which a JavaScript plugin exists. Plug it into a frog, and you have a microservice which your Java application can talk to on localhost
Make today's call
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.
or would you prefer it stays as JSON?
I'm also going to have to decide on a server-to-server protocol for components that run on the testnet-of-testnets, would be cool if some of those components would be written in Java.
@andrew-g-za would you agree with @sappenin's remarks in https://github.com/interledger/rfcs/issues/249#issuecomment-318084843 ?
@michielbdejong yes I totally agree. OER support in java seems to be non-existent, and i've yet to find solid, clear documentation on it in one place - it took me many hours to find anything on what an OER GeneralizedTime object looked like 'on the wire'. This presents an obstacle to adoption for sure. If the argument for moving to binary is around performance then perhaps OER is a reasonable choice, but it certainly not winning any awards for ease of use. In the end choosing OER means that we must provide a rock-solid OER serializer/deserialzer that implementers can use out the box.
oh wow, OER is a missing page here: https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One#Encodings
maybe we can define ILP and LLL in ASN.1 and then still use JSON on the wire
HA - just saw the name on 251 -- never saw the word "lotocol" till now. LLL FTW!