Wietse Wind

Results 56 comments of Wietse Wind

@NetScr1be Your example, `$GHOST`, is perfectly compliant providing it's not how it's stored on the XRPL: it's the text representation of the underlying XRPL value (HEX code) you are referring...

Thank you @scottschurr! Great solution, being able to configure alternative error codes per error. I see that you already added error codes for the most important errors/codes. Going through the...

Hi @scottschurr, sorry for that. Will do right now, lost track of this thread. Thanks for the reminder. I propose the codes below, where a non-standard HTTP code is only...

@scottschurr Thanks, appreciate it :D

Makes sense @mDuo13, thanks for chiming in. Thoughts regarding the version flag: if that same flag would also change the behaviour of other version related options, one would never be...

> Rebased to 1.9.2. @mDuo13 and @WietseWind, are you good with this version of the code? Thanks. Very happy with it :) Thank you!

> I agree that `tooBusy` should have a 50x status code. I don't know that every error should though. I don't think an account not found or transaction not found...

> Is this related to the recent scalability issues the XRPL has been having with Trustlines? No.

@intelliot Yes, I like that.

Addition: Currently, when a `subscribe` command is sent over a WebSocket connection to rippled, the direct response reflects the value provided in the `id` field when sending the subscribe command:...