Re: [PATCH] RFC: Universal scan proposal

[Johannes Berg <johannes@sipsolutions.net>]

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