Thank you for updating ICRC-4 after our related discussions regarding NFTs.
- This is a good question. Including it means that we guarantee that all request elements are processed and that even before starting any processing, it is reasonably guaranteed that processing can be at least attempted for all request items and that there is enough space in the response for responses for all request items. This is all a bit constraining and the more I think about it, the more I like the idea of giving up the ordering. See my write up for the NFT-related transfer method (all arguments apply equally here as well). The variation of Option 2 is what reflects your option, the plain Option 2 is when removing the
transfer: TransferArgfrom each response element and relying on ordering. It seems even nicer to me because of the potential simplifications of the implementation. - In my opinion the approach of relying on ordering of responses and allowing the implementation to terminate anywhere in the sequence, i.e., return only a prefix of all responses, is non constraining for the implementation, i.e., nice. The implementation can do parallel processing as it wants and if a batch-level error happens it does not proceed any further and caps the length of the returned prefix at the largest index it attempted to process in parallel. Elements for which processing has not yet been attempted can receive a
nullresponses to save space. A special error would be semantically equivalent to the error for this case, but consume more space. Thus, doing it that way might make the implementation simpler as it makes fewer guarantees and assumptions.
In your updated API you simplified away the TransferBatchArgs, but you overlooked that it’s still in the method signature. The method parameter should change to vec TransferArg.