quoted

Well, we might not even need different commands. We need different
storage internally, but if you request the results for a given scan
ID then you might get a totally different result format? Though
that wouldn't lend itself well to query "everything you have" which
is also useful. But even then, it could be done by passing the
appropriate "report type" attribute to the dump command - we need
that anyway for trigger.

True. With "report type" attribute you do not mean the actual
report_type thing, right. Hopefully you mean the parameter attribute
that implicitly relates to a "report type". 

Right, I wasn't really thinking in terms of attributes while writing
this. OTOH, something like an attribute *would* be needed, no?

The risk here is that it
requires careful description of what user-space needs to look for if
it gets a notification. I think having separate
notification/retrieval commands lowers the risk of misinterpretation.

Yeah, fair point.

Not sure if we're getting ahead of ourselves. Yes, we have to
determine attributes for each scan "report type", but it is not a
prerequisite for the other topic. 

We'll also have to figure out which report types we need at all :)

I guess to answer the question about the partial results attributes
we need to know what the possible higher-level use-cases are. Other
source of information would be to look what is done for g-scan in
Android "M" or "N", but not sure if that is best approach as we may
not consider all use-cases.

Right.

johannes