Is there a feature flag to skip compiling this legacy logic or is this moot by design and there is no compile/run time cost in these cases.
The general approach is to rely on this TypeResolver trait defined in a very tiny scale-type-resolver library throughout the stack.
What this means is that, if you want to work with historic data, then you can pull in a (not yet created) crate that can give type information about these historic types, but for working with modern runtimes, you just don’t need to bring in those dependencies at all (so eg subxt won’t depend on any code for decoding old types, since it’s only concerned with interacting with the head of a chain right now).
I’d like to avoid needing feature flags where possible, but if we pull old and new decoding together into a single high level create with a nicer interface then we’d end definitely up with feature flags to opt out of the legacy (or modern, perhaps) type decoding if you don’t need it.
If I understand correctly, like this we do not need to index the whole chains extrinsics but would be able to directly access extrinsics of a certain block, no matter if the types changed or not?
The code being built here will basically allow somebody to take the bytes from an old block or storage entry and be able to decode them into some meaningful values. We might provide a high level interface that one can use to connect to an archive node and download/decode bytes from a block or whatever, but we’ll also provide all of the code beneath that so that you can obtain the bytes however you like and then be able to decode them. I hope that answers your question? 