-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal for WASM helpers for bidding functions #250
Conversation
@morlovich - can you join the WICG and link your GH account with your W3C one? |
FLEDGE.md
Outdated
@@ -201,7 +204,8 @@ The function gets called once for each candidate ad in the auction. The argumen | |||
'adComponents': ['https://cdn.com/ad_component_of_bid', | |||
'https://cdn.com/next_ad_component_of_bid', | |||
...], | |||
'biddingDurationMsec': 12 | |||
'biddingDurationMsec': 12, | |||
'wasmHelper': ... /* a WebAssembly.Module object based on interest group's biddingWasmHelperUrl */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe wasmHelper was mainly intended to help with computing a bid – and if so, should it be passed to generateBid() function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yoavweiss: What exactly does joining the WICG mean?
@sbelov: Yes. Thank you. (I totally bookmarked the right position in my editor, and then edited the wrong one. Probably should not operate any heavy machinery today)
(I imagine we may want something like this for scoreAd as well, but one thing at a time).
@@ -109,7 +109,7 @@ The browser will remain in an interest group for only a limited amount of time. | |||
|
|||
The `userBiddingSignals` is for storage of additional metadata that the owner can use during on-device bidding, and the `trustedBiddingSignals*` attributes provide another mechanism for making real-time data available for use at bidding time. | |||
|
|||
The `biddingWasmHelperUrl` field is optional, and lets the bidder provide computationally-expensive subroutines in WebAssembly, rather than JavaScript, to be driven from the JavaScript function provided by `biddingLogicUrl`. If provided, it must point to a WebAssembly binary, delivered with a `application/wasm` mimetype. The corresponding `WebAssembly.Module` will be made available by the browser to the `scoreAd` function. | |||
The `biddingWasmHelperUrl` field is optional, and lets the bidder provide computationally-expensive subroutines in WebAssembly, rather than JavaScript, to be driven from the JavaScript function provided by `biddingLogicUrl`. If provided, it must point to a WebAssembly binary, delivered with a `application/wasm` mimetype. The corresponding `WebAssembly.Module` will be made available by the browser to the `generateBid` function. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely convinced that browserSignals
is the right place to attach the WASM as the WASM isn't exactly a signal coming from the browser like the other browserSignals
members, almost seems better suited to an additional generateBid
argument, but at the same time it seems awkward or wasteful to make every generateBid()
method change their prototype to include an extra WASM parameter if some/many of them aren't using WASM. Anyhow, I don't have a better solution in mind.
My comment here is: should we add a blurb here mentioning how it's made available to generateBid
? e.g. "...as a wasmHelper
member of browserSignals
"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely convinced that
browserSignals
is the right place to attach the WASM as the WASM isn't exactly a signal coming from the browser like the otherbrowserSignals
members
Me neither, which is why I wanted feedback.
almost seems better suited to an additional
generateBid
argument, but at the same time it seems awkward or wasteful to make everygenerateBid()
method change their prototype to include an extra WASM parameter if some/many of them aren't using WASM.
If we add it to the end, they don't have to change it their signature --- extra arguments are ignored. Of course, there is only so often you can pull that trick.
Anyhow, I don't have a better solution in mind.
A global is another option, but it feels awkward.
My comment here is: should we add a blurb here mentioning how it's made available to
generateBid
? e.g. "...as awasmHelper
member ofbrowserSignals
"
Seems redundant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this is an indication that these functions should be taking an options bag, and not positional arguments?
Not sure how to best pass in the module..