-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v1: get node_id automatically #740
base: main
Are you sure you want to change the base?
Conversation
Some prettification/tests/docs is remaining, but the bulk of the work is done. Feedback from maintainers would be appreciated, thanks! |
Hi @shivdhar! Thanks for the PR. I'm not sure this is something we should add to |
Hi @KodrAus ! I actually was surprised when I tried to use the crate and, instead of just calling Also I took a look at the history of the feature in this repo, and the only reason it seems it wasn't included since the beginning is this issue:
However, node ID is quite well defined in the RFC (along with fallback) so I don't see any reason why we shouldn't have a conformant implementation. Another blocker -- way back in 2016 -- seems to have been this:
This seems to have been solved by the mac_address crate though fairly well; it supports most common platforms and seems to be fairly popular and good at its job (over 2.4M downloads), so we're probably in a better place to provide this in 2024. Most other languages let us get a v1 UUID automatically without a mandatory Let me know what you think! |
I think discoverability is definitely an issue, but I also think that's solved by adding an example. My specific concerns with direct support are:
At least I'd like to start with an example, and consider revisiting this in the future if it becomes widely desirable. |
I suppose I fail to understand why a well-understood and well-supported part of the RFC spec shouldn't be a part of its implementation, and indeed hasn't been in all these years. UUIDv1 generation should be automatic and a no-brainer; MAC address integration is sufficiently complex that users shouldn't have to deal with it unless they specifically wish to tweak it. (An example in the docs adds cognitive overhead and another thing to learn about when it should be a library implementation.)
I think I've already noted that the absence of this clearly defined part of the UUID v1 spec was accidental due to ecosystem immaturity back in 2017; the adding another library part is a pain I agree, but should it stop us from implementing missing functionality in this important library? I think not. End-user impact is entirely optional and opt-in with the feature flag too. Let me know if 1. is a good idea to avoid increasing MSRV and eliminating lifetime allocation of the mac address; then I'll work on replacing it. Thanks! |
@shivdhar The method you've proposed is perfectly convenient and I appreciate you taking the time to put a PR together for it, but it simply replaces this: let mac = mac_address::get_mac_address().unwrap().unwrap();
let uuid = uuid::Uuid::now_v1(&mac.bytes()); while also picking semantics of what happens when the address is unavailable on their behalf, without giving you an opportunity to decide what address to use, and by hiding synchronization around it. If another user wants to do any of these things in a different way then we'll either need to add more functionality to support them, or the API will simply not work for them. All together, I don't believe this is something we should support directly in |
v1: Create node_id automatically from the MAC address of the machine, with fallback, according to the rules laid out by RFC 4122.
Advantage:
The user can now call
now_v1_auto()
and get a V1 UUID without needing to figure out how to manually retrieve/create thenode_id
.Performance: Comparable