[Bro-Dev] Rethinking Broker's blocking API

[Robin Sommer]

On Tue, Jan 10, 2017 at 09:38 -0800, you wrote:

>  From a user perspective, it's important to distinguish whether I can
>  ignore a status update, or whether I have to react to it.

Yep, exactly.

>  I would consider more fine-grained classifications arbitrary. In
>  particular, I find 3 levels too complex.

Well, weren't you just saying that two levels are arbitrary? :) I
tried to make it a bit less arbitrary by providing more options. Your
new suggestion goes to back yes/no in terms of whether it's an error
or not, which I think is ok, but you seemed concerned about that.

>  auto s = msg.status();
>    if (s.error())
>      // Compare against error codes for details.
>    else
>      // Compare against status codes for details.

I like this (with the two separate types for error/status code, as
that makes the distinction explicit).

Could we then now also lift the error() method into the message class?
So "if (msg.error())" would be a shortcut for
"if(msg.status().error()? (And then we'd back be where we started I
believe. :-)

Btw, there's one more complexity with all this: when one gets a
status, one cannot tell which operation it belongs to, as it depends
on how thing got queued and processed internally. That can make it
hard to react to something more specifically. But that's something we
can't avoid with the asynchronous processing.

Robin

-- 
Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin