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
We have a development request for the Roma Service. Let me explain what we need.
At the moment, when a request is processed by the BFE service, we get more data and signals from the Key-Value Service. But at this point of time, we don't know all the data we need to use to extract features in the "generateBid" function. The generateBid function executed by the Bidding service doesn't allow us to request more data for feature extraction. A possible solution would be using local storage mounted in JavaScript or WASM code by Roma Service, where we can do feature lookups. In most cases, file sizes for features is larger than 4 GB , so it's impossible to include it in JS or WASM.
To update/upload local storage data, we could use a code fetcher approach when link is provided to the file.
Due to the fact that gVisor is soon available on Roma Service, this feature needs to be implemented there as well. During the public meeting, it was explained that gVisor will run a new process upon request. This means that initialization inside the binary must work quickly and persistent data (read-only) must be available as local storage .
Hi colleagues!
We have a development request for the Roma Service. Let me explain what we need.
At the moment, when a request is processed by the BFE service, we get more data and signals from the Key-Value Service. But at this point of time, we don't know all the data we need to use to extract features in the "generateBid" function. The generateBid function executed by the Bidding service doesn't allow us to request more data for feature extraction. A possible solution would be using local storage mounted in JavaScript or WASM code by Roma Service, where we can do feature lookups. In most cases, file sizes for features is larger than 4 GB , so it's impossible to include it in JS or WASM.
To update/upload local storage data, we could use a code fetcher approach when link is provided to the file.
Due to the fact that gVisor is soon available on Roma Service, this feature needs to be implemented there as well. During the public meeting, it was explained that gVisor will run a new process upon request. This means that initialization inside the binary must work quickly and persistent data (read-only) must be available as local storage .
I think there are simular thoughts/request for Key Value Service: Inline large data structures for caching · Issue #62 · privacysandbox/protected-auction-key-value-service (github.com)
Would it be possible to implement this?
BR, Viacheslav
The text was updated successfully, but these errors were encountered: