Non-source routing (was "failures during the preparation phase")

Thanks all for the input. I'm convinced that it would make sense to at
least support a variety of pathfinding approaches and you all might be
right that non-source routing will end up being the best option.

Looking at the original Internet Protocol RFC
<https://www.ietf.org/rfc/rfc791.txt> it's actually interesting to note
that there are fields that allow the source to specify routing information
(look for the "Loose Source and Record Route" and "Strict Source and Record
Route" options).

Regarding what we called the proposal phase, that's already being removed
from the reference implementation (see five-bells-sender/pull/37
<https://github.com/interledger/five-bells-sender/pull/37> and
five-bells-sender/pull/43
<https://github.com/interledger/five-bells-sender/pull/43>). Now, the
sender will still do the pathfinding but it includes the path in the memo
field as described in this Nested Transfers spec
<https://docs.google.com/document/d/1zTLQLBx0p6-Ds9Ki8nCaVBdXUK4mbJZDQOaz83n6VY8>
.

Supporting non-source-based routing protocols would require additions to
the connector. Anybody want to weigh in on what the best approach for this
would be?

-- 
Evan Schwartz | Software Architect | Ripple
[image: ripple.com] <http://ripple.com>