-
m-relay<rbrunner7:monero.social> SNeedlewoods: I finally found time to look at that priority enum question.
-
m-relay<rbrunner7:monero.social> To me it looks as if the Wallet API definition predates the introduction of the *Priority* / *Very High* fee level, i.e. was defined at a time where really only 3 levels existed. Thus `Priority_Last` does indeed look to me as a way to go the highest fee level, without having to know which one that is; it doesn't mean *Priority* IMO.
-
m-relay<rbrunner7:monero.social> Thus I would opt for b).
-
m-relay<ofrnxmr:monero.social> I think there was a comment on a pr that the last priority isnt necessarily 4, but is the highest
-
m-relay<ofrnxmr:monero.social> disclaimer: My memory may be unreliable
-
m-relay<rbrunner7:monero.social> Yes, any sensible use that I can come up with for `Priority_Last` has to do with getting at the highest existing fee level, whatever it is, whatever it's called. Approach b) would preserve that logic.
-
m-relay<ofrnxmr:monero.social> monero-project/monero #9838#discussion_r2109637110
-
m-relay<ofrnxmr:monero.social> Maybe here
-
m-relay<ofrnxmr:monero.social> monero-project/monero #9838#discussion_r2085345796
-
m-relay<rbrunner7:monero.social> As far as I can see, that PR does not deal with anything Wallet API, except adding a type transfer from enum to int that became necessary because of a change in wallet2. But it makes perfectly clear that the supported fee levels go from 1 to 4, so it's really time to reflect that at long last in the Wallet API.
-
m-relay<ofrnxmr:monero.social> yeah, just the comment/review there
-
m-relay<sneedlewoods_xmr:matrix.org> thank you 🙏