Regarding the *_RESCAN AppAvailability statuses in the current extension implementation:
There are 2 additional availability states in the current implementation: available_rescan and unavailable_rescan. Essentially, an available/unavailable status for a (sink, appId) becomes their _rescan counterpart instead of being discarded when there are no more queries for that appId. By doing this we keep the cached result that can be returned immediately when a sink query for that appId is re-added, but we also re-query the app availability.
I think an alternative approach without the use of _rescan statuses is to:
- retain available/unavailable results even after there are no more queries for the appId
0 rescan unknown/unavailable on user gesture. IIRC, unavailable can become available later due to delayed retrieval of the app list by the receiver.
- It's far less common for available to become unavailable. If we want to account for this, we can cache the result for an hour only.
Regarding broadcast requests: these are currently implemented as getAvailability calls in the Cast SDK where the URL contains a broadcast-specific parameter. This is handled as a sink query in the Cast MRP. We will need to implement logic to special case this in the in-browser Cast MRP.
Based on conversation with chrome-security@, JSON parsing for Cast messages should be done out-of-process using the data_decoder service. Given the frequency of messages, it would be ideal to have batching support.
Comment 1 by imch...@chromium.org
, Feb 22 2018