Re: newcomer "random" doubts about ILP

imho...

You are always going to need some sort of plugin to 'connect' legacy systems to the 'protocol'.
These could be JSON/RPC as far as ILP is concern but could communicate as you like internally.

I think, correct me guys if I am wrong, what's important here is the protocol itself.
There are a few proposed demo's and reference implementations as a starting point but each developer would have to adapt them to their needs as long as the protocol is respected.

> On 22 Jul 2016, at 21:40, Enrique Arizon Benito <enrique.arizon.benito@everis.com> wrote:
> 
> Hi all,
> 
> I'm new to Interledger. I just got a first look at the RFC and the five-bells demo.
> 
> Some doubts arise after reading the docs. I post then next. Fell free to answer if you consider it worth the effort, ignore them or request for more details.
> 
> Some previous context:
>  - I'm interested in the possibility to create an interface connecting existing ledger systems ("banks") with any other ledger/payment system/blockchain technology that accepts the ILP protocol.
> In practice that means implementing a set of JAVA APIs/libraries/servers to "automate" the integration bank <-> ILP connector, front-end <-> bank, ...
>  - For development/testing purposes I was thinking to develop a keep-it-simple-and-stupid in-memory ledger/database
>  and implement around it the different interfaces to interact with the ledger client ("wallet") and the ILP connector.
> 
> My doubts come next:
> 
> 
> * ABOUT THE CLIENT WALLET:
> 
>  - Ussually the ledger (bank) o payment network (paypal, crypto-currency bloc-chain, ...) already has one or more UI front-ends (HTML5, Mobile App, telephone channel, bitcoin-wallet, ... ).
>    For example in the case of a "normal" bank it could be a MVC architecture, with an already established communication protocol/s (XML, JSON, RMI, REST, SOAP...)  and an intermediate application server (JEE, ...) with users connecting through their web browsers/mobile clients.
> 
>    Let's suppose now that we want to add to my already existing apps the functionality  for a ILP compliant wallet:
> 
>    DOUBT: By reading the available docs/RFC, looks to me that the use of the JSON+REST protocols are enforced by the ILP/SPSP/ITP/.. protocol/s.
>       Reuse of any existing transport/communication protocol/s, between client and servers is not contemplated.
> 
> 
>  - Suppose a bank already offers an mobile app for final users to simplify payments to other internal/external bank accounts. Now I would like to reuse such app to allow final users to pay to external payment networks like Paypal, Ripple, Bitcoin, ...(supposing such networks already offer ILP connector support).
> 
>    The user interface will offer the option to pay to:
>        - Internal bank account
>        - External bank account
>        - ILP URI account (receiver)
>        - ...
> 
>    DOUBT: Does this use-case makes sense within the current ILP protocol?
> 
> 
> 
> * ABOUT THE SPSP PROTOCOL:
>  - As I understand it, the SPSP protocol is used to fetch the previous INPUT (payment details, crypto-conditions, ILP connector path) to the ILP protocol, but is not part of the ILP protocol itself.
> 
>    DOUBT: The server used to process the client/wallet SPSP requests (Discovery, Query, Quoting, Setup) can be isolated from the ledger?
>    Looks to me that only the information in the Setup stage must "arrive" to the ledger.
> 
> 
> 
> *  ABOUT ERROR HANDLING:
> 
>  DOUBT: Is there any error handling predefined strategy?
>         for example, all messages from the ledger to the connector must check first if  the response contains payload or exception.
> 
>  DOUBT: Does/will the protocol define a set of predefined exceptions from server to server in case of connector internal error ?
> 
> * ABOUT DEVELOPMENT:
>  I observed that many work has already been done in the five-ledger demo to test the correct behavior. (five-bells-*/test/*).
>  I'm wondering what will be the easier path to start implementing the five-bells-ledger equivalent in java
> 
>  DOUBT: Can the five-bells-wallet/five-bells-connector and related tests be reused while developing a new java-testing-ledger or would it be any technical issues?
> 
> 
> Best Regards,
> 
> Enrique Arizón Benito
> Tel: +34 976 482 080, ext 117064
> http://www.everis.com

> 
> ________________________________
> 
> AVISO DE CONFIDENCIALIDAD.
> Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.
> 
> CONFIDENTIALITY WARNING.
> This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.
> 
> 
**********************DISCLAIMER*****************
This message is private and confidential and it is intended exclusively for the addressee. If you receive this message by mistake, you should not disseminate, distribute or copy this e-mail. Please inform the sender and delete the message and attachments from your system. No confidentiality nor any privilege regarding the information is waived or lost by any mistransmission or malfunction.
Any views or opinions contained in this message are solely those of the author, and do not necessarily represent those of ISBAN, unless otherwise specifically stated and the sender is authorized to do so.
E-mail transmission cannot be guaranteed to be secure, confidential, or
error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. ISBAN does not accept responsibility for any changes, errors or omissions in the contents of this message after it has been sent.
This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.

*********************AVISO LEGAL **********************
Este mensaje es privado y confidencial y solamente para la persona a la que va dirigido. Si usted ha recibido este mensaje por error, no debe revelar, copiar, distribuir o usarlo en ningun sentido. Le rogamos lo comunique al remitente y borre dicho mensaje y cualquier documento adjunto que pudiera contener. No hay renuncia a la confidencialidad ni a ningun privilegio por causa de transmision erronea o mal funcionamiento.
Cualquier opinion expresada en este mensaje pertenece unicamente al autor remitente, y no representa necesariamente la opinion de ISBAN, a no ser que expresamente se diga y el remitente este autorizado para hacerlo.
Los correos electronicos no son seguros, no garantizan la confidencialidad ni la
correcta recepcion de los mismos, dado que pueden ser interceptados,
manipulados, destruidos, llegar con demora o incompletos, o con virus. ISBAN no se hace responsable de los cambios, alteraciones, errores u omisiones que pudieran hacerse al mensaje una vez enviado.
Este mensaje solo tiene una finalidad de informacion, y no debe interpretarse como una oferta de venta o de compra de valores ni de instrumentos financieros relacionados.
Ref:[PDB#015]

Received on Saturday, 23 July 2016 08:24:08 UTC