| 03:58 | <MikeSmith> | zewt: wonder why they bother to use # for the PresentationFramework/src/Framework.. part |
| 03:58 | <MikeSmith> | zewt: that part doesn't look like a familiar fragment anchor at least |
| 03:59 | <MikeSmith> | zewt: and the second # has that problem of causing the URL to be invalid per the URL spec |
| 04:01 | <MikeSmith> | (also nice nostalgic use of frames there) |
| 04:20 | <zewt> | MikeSmith: they do it because that's client-side, not server-side |
| 04:20 | <zewt> | and the url spec is wrong, I think |
| 04:20 | <SamB> | bother that |
| 04:21 | <zewt> | (i don't even know what that means) |
| 04:23 | SamB | is just hopeful about higher-anchors happening at some point ... |
| 04:59 | <zewt> | hotmail represent |
| 23:41 | <zewt> | things that need to die: uuids as random tokens (just use a 128-bit random hex string, avoid a whole silly mess of formatting and bit twiddling) |
| 23:43 | <SamB> | (... won't that make our COM code slower to match those IDs? ;-P) |
| 23:45 | <zewt> | |
| 23:46 | <zewt> | just seeing them in URLs (stereotypically, microsoft URLs) and cringing |
| 23:46 | <zewt> | (they're also completely pointless to use as blob URLs and are just extra stuff to bloat specs, but since everyone's already using them for some reason... oh well) |
| 23:46 | SamB | is not sure if he's joking or not, but he's heard of optimizations related to consecutive GUIDs ...) |
| 23:47 | <zewt> | consecutive IDs aren't random tokens |
| 23:47 | <SamB> | I know |
| 23:47 | <SamB> | at least, clearly not 100% random |
| 23:48 | <zewt> | (though if you use a, say, 116-bit random token and use the rest as a counter, you probably still get enough randomness) |
| 23:48 | <zewt> | (v4 uuids are only 112 bits random to begin with) |