search

interledger-deprecated / java-ilp-core

WE'VE MOVED: This project has moved to Hyperledger Quilt
https://github.com/hyperledger/quilt/tree/master/ilp-core
Apache License 2.0
16 stars 10 forks source link

Discuss ILP Packet Design and Implementation #17

Closed sappenin closed 7 years ago

sappenin commented 7 years ago

See RFC Issue 146 for discussion, and the proposed Interledger Protocol data format and discuss how any of this should be implemented in Java.

adrianhopebailie commented 7 years ago

We definitely need to implement concrete classes for all the packet formats that are being proposed here: https://github.com/interledger/rfcs/pull/168

sappenin commented 7 years ago

@adrianhopebailie I've started looking at interledger/rfcs#168, and it looks like the conditional payment stuff has been removed in that PR. Is the idea that a condition/expiry info for a non-optimisitic-mode payment will be some sort of "custom header" stuffed into the InterledgerProtocolPaymentMessage.data field?

sappenin commented 7 years ago

FYI - I have a provisional interface defined for the InterledgerPacket interface - I'll try to commit tonight or tomorrow for feedback. It's not clear to me if the PaymentPacket and the ILQPPacket and the CCP packets should be distinct "things", or if they should all inherit from a common interface.

adrianhopebailie commented 7 years ago

Awesome!

It's not clear to me if the PaymentPacket and the ILQPPacket and the CCP packets should be distinct "things", or if they should all inherit from a common interface.

They are all distinct packets

sappenin commented 7 years ago

I've created an initial PR for this via PR #24. The packets are distinct classes, but they have some overlapping qualities, so they inherit from the same super-type. Please review and provide recommendations if anyone prefers a different style or design.

Also, be sure to read the "Design Note" in the description of the PR. I think Java ILP Core should provide concrete implementations of these model objects like packets, but IMHO we should also provide interfaces so that other people (me, for example) can create alternative implementations of each of these classes. But for sure, this PR needs to have concrete implementations in it before it's merged.

This idea (interfaces+concrete classes) seems to be somewhat controversial, so we should perhaps discuss this more here, in another issue, or perhaps on the next Java call.

sappenin commented 7 years ago

Closing this issue in deference to PR #28. Please make comments in there, or open a new issue if there are concerns.