4 ms·

My point was, let's start with that large OID tree, for example. And continue this concept downward. Except when it's inside your org, you're the registrar of

My point was, let's start with that large OID tree, for example. And continue this concept downward. Except when it's inside your org, you're the registrar of your namespace's sub-OIDs, and so on. And there's precisely no reason not to have hierarchical sequential ids for everything. You need to generate ids on 100 servers? Good, give each server a namespace. You need to do that in a 100 processes on each server? Good, give a sub-namespace to those too. And the best of all is that the above-organization OID part of the tree is ONLY needed if you show these ids outside your organization. Otherwise you can use the internal private part of the identifiers. So what am I missing here? Maybe they need to be hard to guess, so add a random key part to them (distinct from the generated sequence part) as a "password". Done.

pravus 3y ago
I'll also have the need to make namespaces dynamic and centrally coordinate their lifecycle along with the rest of my infrastructure as I stand up anything that needs some sort of coordinated ID. So I've just moved this issue to an even larger scope with even more complexity. What do I gain for this? UUIDs solve all of this because the chance of creating a duplicate is so low it can effectively be ignored. I can namespace UUIDS and create chains of them if needed. This is the reason both exist. We need both. We can use both.
- 3cats-in-a-coat 3y ago
  When you get used to this basic principle of when you create something, the creator slaps a name on it, it stops being considered a hassle or confusing. More specifically: 1. When you create something, the creator names it. 2. When you bring something you created outside your scope, you prepend your name to it. It's kind of what we do with (actual) children if you think, slightly less structured, but the idea was always there. Just add recursion to complete the principle.
  - pravus 3y ago
    I generate children faster than the birth registry can issue certificates and Cronus eats them before it could be issued anyway. Nesting namespaces doesn't solve the problem of scale within a single namespace.

pravus 3y ago

I'll also have the need to make namespaces dynamic and centrally coordinate their lifecycle along with the rest of my infrastructure as I stand up anything that needs some sort of coordinated ID. So I've just moved this issue to an even larger scope with even more complexity. What do I gain for this? UUIDs solve all of this because the chance of creating a duplicate is so low it can effectively be ignored. I can namespace UUIDS and create chains of them if needed. This is the reason both exist. We need both. We can use both.

3cats-in-a-coat 3y ago
When you get used to this basic principle of when you create something, the creator slaps a name on it, it stops being considered a hassle or confusing. More specifically: 1. When you create something, the creator names it. 2. When you bring something you created outside your scope, you prepend your name to it. It's kind of what we do with (actual) children if you think, slightly less structured, but the idea was always there. Just add recursion to complete the principle.
- pravus 3y ago
  I generate children faster than the birth registry can issue certificates and Cronus eats them before it could be issued anyway. Nesting namespaces doesn't solve the problem of scale within a single namespace.