Hopefully we can also optimize JSON-RPC responses to support something that fast and use pipe-lining to make sure memory will never be a concern.

The dialog state can be quite valuable for platform developers, we can imagine many use cases.
I understand this ca already be use however it is not fast enough in some cases, seems like it could also be traffic impacting since it is holding a lock.

I think it would be a great improvement to make sure we get very fast and "reliable" JSON-RPC access to its state.

I understand 100K may seem to much, but in some scenarios "broken" traffic can create leaking dialogs and extracting the dialog state is one good way to find out what is happening.

Also it is already slowing down a little bit at 10K and "may" impact traffic slightly.
I am not sure I would feel safe about building too much logic around doing many JSON-RPC requests to dialog.list on live servers.

However with such a much faster version I do feel much better doing that.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.