Re: newcomer "random" doubts about ILP

Enrique I think you can reduce a lot of your doubts, if you limit the usecase for an implementation to a ledger to ledger communication. If you start to look at ILP for wallets/clients and apps I would express similar doubts as you have.

Lucas
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Am 23. Juli 2016 10:23:35 MESZ, schrieb "Romero, Javier (ISBANUK)" <Javier.RomeroColomo@isbanuk.com>:
>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]