Job ID generation

[SEAPUNK]

Ignore the babble, I'm using UUIDs now

---

Job IDs will be done by an ID broker (which is the manager) to prevent race conditions. The Job ID format should be Date.now() + counter. The counter resets to 0 every time the Date.now() time changes, so you can have multiple jobs created in the same ms. Date.now() will be a good safeguard in the sense of if we do not "store" job IDs, we will not need to keep track of collisions.

[SEAPUNK]

OR, how about this for job ID generation:

• One Date.now() that is kept for the duration of the program.
• One counter that increments every time.

The only time collision can happen is:

• Time is adjusted, AND program stores the date on the exact millisecond the other instances stored the date and generated IDs with.
  • If we really want to guard against that without storing IDs in a database, and doing unique checks like that, we could also put on a few random bytes on top of either the date, or the counter. The more randomness, the tinier the chance.
• [ ] Is having the time included as an ID a security issue? Very unlikely, but I'll keep track of it for now.

[SEAPUNK]

Okay, I will make Job ID generation like this for now (changing the generator, until we finally add solid job storage, will not be a breaking change):

Date.now(), stored at time of manager creation (no waiting of 1ms), with a counter.

[SEAPUNK]

See: #14 We're using UUIDs now.

[SEAPUNK]

UUIDs are perfectly fine.