feat: add simplified flow for http-ilp#319
feat: add simplified flow for http-ilp#319michielbdejong wants to merge 2 commits intomj-pay-headerfrom
Conversation
As @sharafian correctly remarked, there is nothing "streaming" about this flow in the POST case (even though the http content does flow in the GET case), so renaming it to "simplified"
michielbdejong
changed the title
sharafian
left a comment
sharafian
left a comment
There was a problem hiding this comment.
Makes sense in theory, but let's hold off on putting it into the actual spec until we're using it in implementation. Otherwise someone who wants to implement a tool for ILP HTTP might read this section and get confused
|
OK, but we're already using this to achieve streaming payments in the tutorials, so what should we do about that, then? |
Not sure I agree. These specs are supposed to be drafts of ideas looking for feedback. We shouldn't hold anything back. The best way to get feedback is make the ideas public and gather experience from implementors. Right now this whole IL RFC is "invisible" because no version has ever been merged into master. I think that is a mistake. |
|
I'm also not sure what the advantage of this is as compared to the existing HTTP ILP flow. Are you proposing that implementations should include both or should there be two incompatible HTTP ILP flows described here? |
Try out https://interledger.org/tutorials/trustlines and you'll see that it streams hundreds of letters per second, as the response body of one single (streamed) http GET request. Doing that with the existing HTTP ILP flow would require a lot of individual http GET requests, one for each letter, right? That would be a lot of overhead, so avoiding that overhead is the advantage. |
|
I guess this is now no longer an Interledger-only question, maybe we should discuss the |
|
@sharafian in the meantime, do you now at least see the advantage of this as compared to the existing HTTP ILP flow? So can we merge this? If not, then let's schedule a 1:1 chat about this. |
|
Merging this in to #329, will reopen as a PR once discussion reaches a consensus. |
3 participants
No description provided.