Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Adrian Hope-Bailie
    @adrianhopebailie
    Maybe the answer is to remove the constructors and to have some static initializers instead?
    Enrique Arizón Benito
    @earizon
    Umm, not sure static initializers will help. My vote goes for continuing with byte[] but maybe someone else knows some "magical trick" of Java to sub-type byte[] without the need to wrap in a new class (I'm missing the C "typedef" at this moment)
    Adrian Hope-Bailie
    @adrianhopebailie
    I should have said static factory methods. It doesn't provide type safety but it should protect developers from themselves.
    David Fuelling
    @sappenin
    Not sure that we want to have a strong dependency on this in the ILP projects, but in my implementations I've been using immutables.github.io to avoid boilerplate. They have the concept of a type-wrapper, which sort of does what @earizon is looking for. See http://immutables.github.io/immutable.html#wrapper-types
    Adrian Hope-Bailie
    @adrianhopebailie

    Not sure that we want to have a strong dependency on this in the ILP projects

    No. Maybe we should be looking at some other projects for examples.

    As I understand it the goal is type safety. i.e. Don't allow someone to pass in an argument that is unintended or wrong.

    David Fuelling
    @sappenin
    Yep - the example I showed was basically a way to do light-weight, type-safe wrapping of primitive values.
    but one could probably just write that by-hand in this case to avoid the dependency
    Enrique Arizón Benito
    @earizon
    FYI: interledger/java-ilp-core#21
    @sappenin I wasn't aware of this library. I have to look at it "with care".
    Andrew Gates
    @andrew-g-za
    Hi everyone,
    thanks for your earlier responses on packaging the ILP libraries. I think we should try find the next convenient point for each libraries to start making releases, since some are under active development (but the sooner the better IMHO).
    On a related note, i have started making changes to the java-spsp-client-spring repo based on the new SPSP changes. It will also include some changes in java-ilp-core. I'm also looking into PSK to see what i can do there. @sappenin - i'll need to refer to an ILP packet which i believe you are busy with, so i'll keep an eye out on that.
    David Fuelling
    @sappenin
    I hope to get something committed today, but if you want to check-in and empty interface or just something you can compile against, I can update after you.
    David Fuelling
    @sappenin
    Hey All, I spent some time this weekend working on an implementation of InterledgerPacket. I didn't commit anything yet because I want to better understand the final designs of the Error and quoting packets, and how they relate to the main Payment packet, and how extensibility will/should be handled. For example, feel free to comment on interledger/rfcs#189 if you have any thoughts/opinions.
    @earizon Not sure how you feel about the Exception code that was merged - at least we have something for now, but I spent a lot of time thinking about your comments about how best to throw exceptions. If you want, we could continue the discussion in the other PR, but at least we can move on to other code in ILP Java while we consider how best to design the exceptions?
    Enrique Arizón Benito
    @earizon
    @sappenin Hi, I developed it to have "something in place" that just work. I guess changes will hapen as code and use-cases surge. I consider myself a gardener (http://www.chrisaitchison.com/2011/05/03/you-are-not-a-software-engineer/)
    David Fuelling
    @sappenin
    I like it!
    David Fuelling
    @sappenin

    Hi All,

    Apologies for the very late agenda, but we will be having our "every-other-week" ILP Java community call in about 1.5 hours at 9:30am PST.

    Here's a rough agenda:
    Discuss ILP Packet implementation (PR #24)
    Discuss default library design relating to Interfaces vs Classes.
    Discuss java-ilp-core issue #9
    Community project updates
    Other business
    Next steps for the following two weeks.
    Thanks!
    david

    Time: 9:30am PST
    BlueJeans: https://bluejeans.com/910408466

    David Fuelling
    @sappenin
    Hey all, great call today - for posterity, here are a link to the call agenda and some notes that I took: https://docs.google.com/document/d/1AenpP_qw9UXlMMHvUh462n_BqdtrghQKexnyIYUFn_8/edit#
    Andrew Gates
    @andrew-g-za
    Hi everyone,
    I've created a PR for a first attempt at the PSK RFC - interledger/java-ilp-core#26
    all comments welcome :)
    David Fuelling
    @sappenin
    Hi Andrew, thanks for publishing your PR. I've only take a brief glance, but hope to spend more time on it before wednesday's call.
    Andrew Gates
    @andrew-g-za
    Hi David, no worries, thanks for pointing out the debate about the headers. P.s. I'm travelling at the moment so wont be able to make tomorrows call.
    David Fuelling
    @sappenin
    No worries @andrew-g-za! This week was a pretty quick call, but I added notes to the Google doc here: https://docs.google.com/document/d/1AenpP_qw9UXlMMHvUh462n_BqdtrghQKexnyIYUFn_8/
    Enrique Arizón Benito
    @earizon
    Hi all, as commented with David, the java-vert-ledger is starting to take shape. I cleaned lot of code from the October version. At this moment I'm working on my personal github account ( https://github.com/earizon/java-vertx-ledger). Still plenty of TODOs and code cleaning, but five-bells-ledgers tests for accounts start "passing".
    The idea is to put into interledger, but I prefer to make it more stable and cleaner, so that newcomers don't get confused.
    Adrian Hope-Bailie
    @adrianhopebailie
    Hey guys, sorry I missed the call!
    I'm in workshops this week but hope to have time on the plane to do some reviews etc
    If you have a moment please vote on this: https://bugs.chromium.org/p/chromium/issues/detail?id=715577
    Adding support for Interledger to Chrome's implementation of PaymentRequest
    David Fuelling
    @sappenin
    Done!
    David Fuelling
    @sappenin
    @earizon Not sure how the rest of the group feels, but my preference (for now, till we figure out a governance structure for the Java code) would be to keep implementations in their own repos and then just add links to them in the java-ilp-core project's README. That way there's a primary Interledger code-case that defines base-level Interledger concepts (that hopefully all projects use) and then a menu of implementations that anyone can use and contribute to.
    Adrian Hope-Bailie
    @adrianhopebailie
    :+1:
    Although, right now there is a lot of implementation in there
    Agree we need a way to differentiate between core assets and implementations
    lelorrieta
    @lelorrieta

    Hi everyone,This is Laura and Juan Carlos, we work for everis with Isaac and Enrique, and we are going to help with the development.

    We were looking at the code of “java-ilp-core” and we have a question,

    The code implemented in the class “LedgerSpecificDecimalMonetaryAmountFormat” and we would like to know where are the specifications of the class in the documentation.

    Also, we would like to know where are the libraries “javax.money”, if we have to download them or something. Because our Eclipse doesn’t recognize them.

    Adrian Hope-Bailie
    @adrianhopebailie
    javax.money is a JSR that proposes a whole lot of new money related functionality. More here: https://javamoney.github.io/
    LedgerSpecificDecimalMonetaryAmountFormat is an implementation of a formatter (as defined in that spec) that has dynamic formatting rules based on the scale and precision of a ledger
    lelorrieta
    @lelorrieta
    Ok! thanks!
    Enrique Arizón Benito
    @earizon

    @lelorrieta java-ilp-core is using gradle for building . Either you directly use the gradle plugin in eclipse to update the dependencies automatically or, from the command line, follow next steps:
    1 - navigate to the java-ilpc-core directory
    2 - execute
    gradle install
    gradle eclipse
    (will update .project file)
    3 - In eclipse, press F5 (refresh) on the java-ilp-core project. Eclipse will re-read the .project file and update dependencies.

    Note: In the dependencies section of the java-ilp-core/build.gradle you will also find the "coordinates" used by gradle to identify the javax money library in the gradle jar repository. Gradle will download the corresponding jar to a route similar to ${HOME}/.gradle/cache/.../money-api.1.0.1.jar when executing "gradle install". You can then add it manually to your project in eclipse (not recomended, just as a last option if nothing else work).

    In Eclipse, maybe you need first to right-click on the java-ilp-core project, choose "Configure" -> Add gradle nature to make eclipse "aware of gradle " for this particular project.
    David Fuelling
    @sappenin
    All, here's a link to the ILP Java call agenda -- feel free to suggest any additions, either here or during the call. https://docs.google.com/document/d/1AenpP_qw9UXlMMHvUh462n_BqdtrghQKexnyIYUFn_8/edit#heading=h.e7t58zfj9kvz
    David Fuelling
    @sappenin
    Hi All, just in case you didn't see this in the github chatter, I've added a wiki explanation of how to use the new Codec framework for java-ilp-core. This allows for the reading/writing of Java ILP objects to/from ASN.1 OER (and in the future, JSON, Protobuf, or whatever encoding you prefer). https://github.com/interledger/java-ilp-core/wiki/InterledgerPacket-Handling-Framework
    Enrique Arizón Benito
    @earizon
    branch earizon-JavaVertXLedger
    Enrique Arizón Benito
    @earizon
    David Fuelling
    @sappenin
    Enrique Arizón Benito
    @earizon
    Michiel de Jong
    @michielbdejong
    interledger/rfcs#198