The proto representation looks good to me. I have a couple of suggestions based on prior experience designing proto-based data formats.
- I recommend the use of enums rather than strings for values that are constrained to a small, fixed-size set. For example, the dtype field in the Tensor message should probably (I think!) be an enum. - I don't know the use case for the google.protobuf.Any fields in the spec, but in general I would recommend making these specific message types or 'oneof' fields whenever possible. - There may be places that you wish to tighten up the semantics of the existing log format, rather than simply encoding the existing format as a proto. For example, I would recommend being explicit about the meaning of the 'version' field (e.g., should this be a SemVer-type version string?). Likewise, use of a float value for timestamps can lead to imprecision, unless timestamp means something different here than it does in most other systems -- uint64 storing microseconds since the epoch, or a string holding an ISO-8601 formatted timestamp would be better. - For the case of the Config message, if you believe it will soon change or differ based on new functionality coming along, consider using a oneof field with a single submessage for the existing Config. --- [Visit Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/14) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/7d0b1574198fbd766dc61f4b9ebf255fc97b9dc2c138805947e308c26b0df32c).
