Hi Emeric, On Fri, Mar 20, 2020 at 02:29:48PM +0100, Emeric Brun wrote: > So I understand that since 1.6 the SMP_T are directly announced on the wire > for key types, and it brokes the documented values and this is hazardous to > rely on internal enum values.
Yes that's the issue Tim spotted. > So we must re-introduce a mapping between internal and on-wire types. Indeed. > Some questions about choices: > > - Re-map types to documented values or Update the doc to match currently used > values? I'd say that what's currently on the wire seems to more or less match the doc. Given that there are very few peers implementations, what's working right now seems the most important to me. So I'd suggest that we change the code to perform the mapping again and that we possibly update the doc in case it's wrong on some of them. > - About re-introduce the mapping, I'm not sure we should re-introduce the > mapping between fetches and tables types. Table types could stay internal, > using SMP_T... and we could map to protocol's values only when emitting the > message. I didn't think about this possibility but I actually think it might be the best one. The reason the types were changed was to simplify the resolution of casts in "stick" rules, because if you remember we used to have two types of casts in the past, sample-to-sample and sample-to-table. But with your suggestion we'd keep the internals clean and simple to maintain and only the protocol would be adjusted on the wire, which is in fact what any agent should do. I really like this approach! You'll the probably just need to define some PEERS_TABLE_TYPE_XXX for example and map the table->type from SMP_T_* to those types and conversely, that sounds really clean. Thanks, Willy
