Of geek interest: UUIDs have been around for a long time and they work well and interoperate fine, but the specification space is a mess. So the IETF just shipped RFC9562; it has a fine consideration of the history and the trade-offs involved in all the different flavors of UUIDs, and is well-written and I think, as of now, the place to start looking if something UUID-flavored is puzzling you. Strong work! https://www.rfc-editor.org/rfc/rfc9562.html
@timbray One thing I’ve always wondered is: why does the XML spec not allow id attributes to begin with numbers? It would make using UUIDs in XML simpler to allow numbers for the first chart, no?
Apollo brings back memories
my boss got an Apollo workstation and told us the hard drive had 650 MB and we all gasped in disbelief at unlimited cosmic power
@timbray
“UUID should be represented by the "hex-and-dash" string format consisting of multiple groups of uppercase or lowercase alphanumeric hexadecimal characters “
Every time I’m handling uuids in code I need to remember to think about case. I have seen resource IDs in azure recently consisting of multiple uuids in the one resource ID string. where some UUIDs are in caps and others are lower case. In the same ID string. But if you were building that resource ID string to use in an azure SDK you would have to respect which UUIDs are in caps and which are lc otherwise it will not be useable. It’s an absolute nightmare.
because the standard allows both and some library code has not implemented the standard correctly, we get issues with case. #Azure#UUID
@spmatich 1/ Trying to figure out when that would be a problem. In my experience, UUIDs are mostly database keys or just convenient representation of random quantities for shard selection. When I remember a database key that happens to be a UUID, I'm going to remember it as a string literal and use that for retrieval. When I generate one to select a shard who cares once the shard has been selected?
@spmatich@timbray Reminds me of the time some web devs complained that they can't store a UUID in 32 Bytes due to the dashes, and ended up choosing 16 random Bytes they stored as a hex string.
It led me to conclude that the problem with UUIDs is that they're way too simple and sensible.
@jens@timbray omg. You could store the hex encoded uuid string without the dashes if you really needed to. The dashes are always in the same place. When you read them back just add the bloody dashes back in.
@spmatich@timbray Yes, that's why I call them web devs. That was their background, but in the project they were doing stuff in Rust with binary blobs, so it should've clicked.
Add comment