Did a bit more digging. Each day it all makes a bit more sense. Now I’m getting ready to make the helper methods that will assemble the operations that will ultimately be put into the commit_batch method as an argument. I put together a game plan for programmatically updating the assets of front end canisters. I’d like to run it by you all here before I write all the code. I’ll be using the list({}) method (within the asset canister) and type BatchOperationKind below, I’ve listed the function signature and the type definition:
list ({}) -> ([{
key: Key;
content_type: Text;
encodings: [{
content_encoding: Text;
sha256: ? Blob; // sha256 of entire asset encoding, calculated by dfx and passed in SetAssetContentArguments
length: Nat; // Size of this encoding's blob. Calculated when uploading assets.
modified: Time;
}];
}])
The BatchOperationKind is defined like so:
type BatchOperationKind = variant {
CreateAsset: CreateAssetArguments;
SetAssetContent: SetAssetContentArguments;
UnsetAssetContent: UnsetAssetContentArguments;
DeleteAsset: DeleteAssetArguments;
Clear: ClearArguments;
};
type CreateAssetArguments = record {
key: Key;
content_type: text;
max_age: opt nat64;
headers: opt vec HeaderField;
enable_aliasing: opt bool;
allow_raw_access: opt bool;
};
type SetAssetContentArguments = record {
key: Key;
content_encoding: text;
chunk_ids: vec ChunkId;
sha256: opt blob;
};
type UnsetAssetContentArguments = record {
key: Key;
content_encoding: text;
};
type DeleteAssetArguments = record {
key: Key;
};
type ClearArguments = record {};
The plan is as follows:
1.) Maintain a master copy of the asset canister. this asset canister will be within my control and I will be updating it via the DFX SDK command.
2.) create a store canister. the store canister will also be a controller of the master copy asset canister, thus authorizing it to retrieve the assets data that the master copy holds. I’ll be using the list({}) method (within the master copy of the asset canister) to retrieve the assets data. Once the store canister retrieves the updated assets data from the master copy, it will then store that data within its stable memory. There, the updated assets data can be retrieved by any canister via a shared method.
3.) Create a manager canister for each of the asset canisters that are due to receive updates. The manager canisters will each be a controller of their own respective assets canister. The manager canister will be programmed to: first, pull the assets data from the store canister, then manipulate the data so that it conforms to the type BatchOperationKind, and finally commit those updates to their respective assets canisters via the commit_batch method that exists within the assets canisters.
is there any reason why this wouldn’t work? particularly with respect to step 3? is there any reason why i wouldn’t be able to use the data that I get from the list({}) method’s result in order to produce the type CreateAssetArguments or the type SetAssetContentArguments? my worry is that sha256: opt blob may be created such that the canister for which the sha256 hash was created is the only canister that is able to interpret/decrypt it, and as a result, using it to update the assets of another canister would cause issues. @peterparker, @Severin
