IdP3 Clustering...

[Cantor, Scott]

> Now this is an interesting idea...  I'm not sure if it's what Jim was
> saying though.

Then I'm confused, but I don't see any other way for two nodes not in sync to independently end up storing the same value.

> For the purpose of releasing a persistent NameID, a master-slave or
> "eventually consistent" database could work fine.  If the persistent
> NameID is generated on the fly and stored in the database, then it isn't
> crucial that the replication happen in real-time.  If node A generates a
> NameID but Node B doesn't see it right away and generates the same
> NameID, that's okay.

Right. That's just not how the current code works with the exception of the first generated value. After that it's random. That has turned out to be a bad idea, and I suspect we could evolve the code away from that but nobody's asked. UW could probably just donate their code in fact (might already be on the Contributions page, didn't check).

> If an admin wants to revoke or change the stored NameID value, it probably
> doesn't need to update in real-time on all nodes.

Anything after the first one has to involve a perturbation of state that has to be injected from outside the system and has to be the same on all nodes. But that's sufficiently rare as to be a simple thing to do manually at worst.

-- Scott