Possible extension of v1 UUIDs

[ctavan]

A thing came in mind when I was running some tests with v1 UUIDs: Should we allow the user of the v1() method to optionally specify a timestamp that will be used instead of Date().getTime()?

There are two cases in which this might make sense:

1. For testing (clock sequence stuff)
2. If you want to do range selections on a range of v1 UUID's and need to generate the corresponding start- and end-UUID's.

I see that we're getting to a point where we're tempted to make node-uuid bloated which should be avoided IMO. I therefore had the idea of using node-uuid as the underlying fast & lightweight uuid generator for a wrapper similar to uuid-js that provides you with some convenience methods like conversion between string- and buffer-representation, validation, extraction of the timestamp, etc, see my discussion with @pnegri: https://github.com/pnegri/uuid-js/issues/10

He also had the brilliant idea of naming it node-uuid-utils which I really like.

Being able to specify the timestamp when calling v1() would be the only addition to node-uuid I can think of right now that would be needed to build node-uuid-utils. What do you think?

[broofa]

Christoph, let me think about this. My initial reaction is that what you're proposing here seems like a special case of the "compose a UUID" problem, which may be better addressed by having a utility method that allows you to specify some/all of the fields defined in sect 4.1, and composes the UUID for you. (And writing that is probably non-trivial and likely to add significant code bloat.)

Let's leave this out of the v1 diff for now and wait until we've got some concrete examples of how people might need/use this before moving forward here.

[broofa]

[reopening in case others have thoughts on this]

I could see doing something like the following. Maybe. :) ...

function uuid([options[, buffer[, offset]]])

• options - options object, may contain...

{
  random: (Array)      // (v1/v4) random #'s to use instead of rnds
  format: (String),    // (v1/v4) equivalient to current 'fmt' argument,
  timestamp: (Number), // (v1) timestamp to use
  clockseq: (Number),  // (v1) clockseq to use
}

• buffer - Array/buffer to write into
• offset - offset into buffer to begin writing

Thoughts?

[ctavan]

Looks good to me. Especially since we don't have to break anything to make it work.

[pnegri]

Following this close. Keep good work.

[ctavan]

If we do this, we should allow specifying the node as well. Maybe somebody has access to the mac-address and really wants RFC compliant v1 uuids...

{
  random: (Array)      // (v1/v4) random #'s to use instead of rnds
  format: (String),    // (v1/v4) equivalient to current 'fmt' argument,
  timestamp: (Number), // (v1) timestamp to use (in UNIX epoch)
  clockseq: (Number),  // (v1) clockseq to use
  node: (Number) // (v1) node. it's a 48bit integer, so maybe we must use a byte-array?
}

Another thing: we measure times in UUID epoch throughout the lib now, but I think when specifying a timestamp as an option we must use UNIX-time to avoid confusion.

[ctavan]

I have added a pull request for this one, I think we can continue discussion there: #16

[pnegri]

about the node value i was thinking about using a byte replace in only node part at the client or util. trying to dont add boilerplate. but its great like that.

[broofa]

we must use UNIX-time to avoid confusion

agree.