Emile Cormier

> one question though: > > > The dealer may send the RESULT, or the CANCEL, at its discretion. > > Probably good idea to leave that open to an...

> I agree with all of this. This is what I think, off hand, would be most intuitive: > - (A) The callee must ignore the INTERRUPT. > - (B)...

> Guess it's a typo, but INTERRUPT is only received by callees (not callers). Ugh, sorry, no it wasn't a typo. I was wrongly thinking that it was _callers_ that...

> Why would you not let the calleR decide when to (and handle the) debounce? @Jopie64 , consider the use case where the RPC is used to activate a big...

In the original forum thread, Konstantin Burkalev (aka [KSDaemon](https://github.com/KSDaemon)) posted this reply: > Well, may be thats not clearly specified in spec, but my opinion is, that > all WAMP...

Yet another scenario is when a client _doesn't_ announce support for an advanced feature, yet goes ahead and uses it anyway. Here's a rough sketch of what I think the...

Here's another idea. As I proposed above, the `HELLO.Details.roles` dictionary enumerates **all** the features supported by the **client implementation**. If the client library user has requirements on features provided by...

I know it would be tedious, but I think we should analyze the use of unsupported features on a case-by-case basis. If it's possible to generalize the behavior for most...

I've compiled the list of misuse cases in this read-only Google Spreadsheet: https://docs.google.com/spreadsheets/d/1bP6RtLTXySlvsqS0kuCZ97u7OFnHlSsTqwx3r0F-L4A/edit?usp=sharing I will convert this spreadsheet into a Markdown or HTML table, and will find a place to...

Let's go back to the following misuse case: > If a publisher attempts to use blacklisting, but the broker does not support that feature and silently ignores the blacklisting option,...