You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As currently designed, vendor scripts running within an iframe are unable to get responses from most commands. Most commands do not support callbacks, but the example stub code assumes all commands do support callbacks.
Also, given that most commands use synchronous return values as opposed to asynchronous callback functions adds complexity for vendor scripts running inside iframes. A proxy interface (similar to one defined in the TCF design) can not be created in a way that allows vendor scripts to call the proxy the same way they would call the real CMP. This is due to the fact that all cross-frame communication is inherently asynchronous.
Solution 1 (recommended) - Remove direct return values from all commands and rely solely on callbacks
Pros
Aligns with TCF design, allowing for an easier transition to GPP
Allows for a proxy interface to be created in a way that vendor scripts need not know whether they are running in the same frame as the CMP or in an iframe
Cons
Requires a more significant update to the design
Solution 2 - Leave CMP interface as is. Update example stub code to respond to postMessage calls with direct return values as well as callbacks from the command.
Pros
Reduces changes needed to current GPP design
Cons
Adds complexity to vendor script. A proxy interface could be created, but it would differ from the CMP design as all commands would need to support callbacks in the proxy interface.
If a vendor script is running in an iframe which it does not control, the script that controls the iframe would be responsible for ensuring the vendor script could access the CMP properly.
Solution 3 - Update all commands to support both a return value and a callback. If a callback is passed, then the command should use it. Otherwise, the command should return a value.
Pros
Doesn't break the existing design for most commands. The behavior only changes if a callback function is passed to a command that previously did not support it.
The addEventListener command might need a breaking change. The initial response to the command is only passed as a return value. This may need to change to be passed as both a return value and to the callback.
Allows for a proxy interface to be created that is similar (but not identical) to the CMP. The difference being that only the callback is supported.
Cons
Still adds potential confusion and complexity in vendor scripts running within iframes
While I believe Solution 1 should be the preferred approach, if there is too much concern making significant changes at this time, Solution 3 may be sufficient (though not ideal).
The text was updated successfully, but these errors were encountered:
Problem
As currently designed, vendor scripts running within an iframe are unable to get responses from most commands. Most commands do not support callbacks, but the example stub code assumes all commands do support callbacks.
Also, given that most commands use synchronous return values as opposed to asynchronous callback functions adds complexity for vendor scripts running inside iframes. A proxy interface (similar to one defined in the TCF design) can not be created in a way that allows vendor scripts to call the proxy the same way they would call the real CMP. This is due to the fact that all cross-frame communication is inherently asynchronous.
Solution 1 (recommended) - Remove direct return values from all commands and rely solely on callbacks
Pros
Cons
Solution 2 - Leave CMP interface as is. Update example stub code to respond to postMessage calls with direct return values as well as callbacks from the command.
Pros
Cons
Solution 3 - Update all commands to support both a return value and a callback. If a callback is passed, then the command should use it. Otherwise, the command should return a value.
Pros
Cons
While I believe Solution 1 should be the preferred approach, if there is too much concern making significant changes at this time, Solution 3 may be sufficient (though not ideal).
The text was updated successfully, but these errors were encountered: