> > 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
