Scott Fleckenstein

@jedmccaleb moving away from the url wouldn't be compliant with https://tools.ietf.org/html/rfc7807 I'm a bit miffed that our first instinct is that the server is designed wrong in this situation when...

> According to specification, it's possible to extend problem object: Extension Members. If we're just going to use the "Do whatever you want" features of the spec to avoid using...

I don't understand why you need to know that horizon accepted the transaction. The fact that it accepted the transaction is zero guarantee that it will show up in the...

It's worth noting that the whole point of horizon's transaction posting subsystem is to simplify integration... If you prefer to manage the state yourself, just post directly to stellar core...

Yep, I think that is valid. It will reduce the instances of feedback-less errors while keeping the integration requirements the same. I'll look into what it takes to fix later...

@jedmccaleb can you give me another example order book to work from so we're on the same page? I'll work on a test scenario but I'd love to have some...

As in streaming this data across two separate TCP connections? There's no coordination between multiple streams... the order you will get responses on the client side will be undefined behavior.

This information is provided by the root resource. I'll change the ticket name to something that reflects that.

Could you give some specifics for "info in the current ledger"?

great point. We should definitely have some docs for the root resource.