v1 UUIDs

[rrichardson]

Is there a desire to have such a thing in this crate?

They would mutually exclusive with the [nostd] directive, since time::get_time would be the preferred method for getting at least 60 bits of precision of time since 1582.

In addition, it would need to take a context in order to store a counter in case of clock collisions due to low resolution on a platform.

Also "Node ID" is a vague notion, usually the mac address, but I assume we'd just want to let someone pass in 16 bytes for that.

So an interface might be:

pub fn new_v1_context() -> UUidV1Context;  

pub fn new_v1(&UUidV1Context,  &[u8; 16]) -> Uuid; 

}

The context would be internally mutable, using, say, a local atomic uint counter.

Thoughts?

[alexcrichton]

Adding support seems fine by me! I'd prefer to keep the crate relatively slim on dependencies (e.g. if we need time keeping or local mac support then this may be best done in a separate crate), but if we can add support here for construction that seems reasonable.

[rrichardson]

If we wanted to avoid a dependency on time, that is do-able, we could just take a u64 and u32 that would correspond to the sec and nsec fraction from time::timespec.

However, I don't think that there is a way to avoid a dependency on sync::atomic

If that is acceptable, I can start working on this.

[alexcrichton]

Sounds great to me! (using atomics is totally fine)

[kw217]

I'd love to have v1 UUIDs too.

[rushmorem]

@alexcrichton Now that v1 has landed, can we get a release? I have been using master to generate v1 UUIDs successfully.

[alexcrichton]

Certainly, published now!