On 2022-09-13 17:51, Thomas Passin wrote: > It's far from clear to me that any code that uses gnx's needs to know > anything except their string value. You want to avoid inadvertent > duplications of gnx's (so copies can be distinguished from clones, for one > thing), that's clear. Not that I've studied the code or anything useful > like that! it ought to be possible to combine a UUID with the user name, > so people to whom it matters (like @edward) could still see that. > > Don't forget, there are several kinds of UUIDs. Some are more > collision-proof than others, or harder to generate, or the scope of > uniqueness varies (e.g., local computer vs the world). ISTR that > TheOldNewThing had a post or series of posts on the differences between > different kinds of UUIDs. > > File format changes should be backwards compatible - Please Please Please! > On Tuesday, September 13, 2022 at 6:17:54 PM UTC-4 Edward K. Ream wrote: > >> On Tuesday, September 13, 2022 at 4:36:05 PM UTC-5 spike wrote: >> >> Having read the discussion on #1348 (thank you for the link), I must >>> strongly disagree with this assessment. >>> >>> There were two problems involved in that bug: >>> 1) Leo created a spurious vnode when reading an outline. >>> 2) This exposed a timing race due to using timestamp based IDs. >>> >>> Introducing UUIDs was a proposed solution. Sequence numbers were the >>> chosen alternative. Both were reasonable. >>> >> >> Interesting. I don't remember the details, so you may well be correct. >> >> Using username and timestamp information in your workflow is both fair >>> and reasonable. Blaming UUIDs for a bug caused by improper use of >>> timestamps is neither. >>> >> >> Thanks for these remarks. All I remember was the pain of the bugs, so >> perhaps you are correct that UUIDs were not the real culprit. This is not a >> hot button issue for me. I'm often wrong about details. >> >> It seems we both agree that the present scheme is reasonable. Let's leave >> it at that. >> >> Anyway, it's way too late to consider significant changes to Leo for >> 6.7.0, and any change to Leo's file format qualifies as a *highly* >> significant change :-) >> >> Edward >> > IDs should always be treated as blind tokens. Attempting to decode them is asking for trouble precisely because it causes compatibility problems and hard to trace bugs. The token generator needs to check against existing tokens to verify uniqueness (Leo does this) and may perform heuristics if it needs to ensure sequencing, but care must be taken to safely handle unexpected input.
Leo decodes gnx in exactly two places: The unit test for the token generator, which should never see tokens created by a different version and thus is safe. The ToDo plugin, in todo.py on line 1303. It takes proper precautions to fail gracefully when it hits an ID it can't read because failures were a known and expected issue when it was first created. Even something as simple as a '.' in a user name is enough to trip it up. There is a more general problem in Leo with not escaping output, which can create unreadable files if unexpected characters are present. Raw gnxes are written to both .leo files and in @file annotations, preventing the use of the characters '<', '>', '"', '&', ':', and '\n'. None of those characters occur in UUIDs, which are limited to [0-9A-F] and '-'. My proposed patch used UUID4, which are randomly generated and provide strong guarantees of uniqueness. It was also gated by a user setting that defaulted to 'off'. UUID gnx is verified compatible with any recent Leo and should be compatible all the way back to 4.1. That's why I felt comfortable submitting it for 6.7.0. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/5fb0ec1d-0f03-39ea-a64e-7f1d3f8c5ded%40runbox.com.
