On Wed, 15 Oct 2014 10:21:37 -0500 "Edward K. Ream" <edream...@gmail.com> wrote:
> On Wed, Oct 15, 2014 at 9:18 AM, 'Terry Brown' wrote: > > >> > So for maximum code cleanliness Bob's fix could be removed. > > >> I don't see how that statement can be correct. Each invocation of > >> Leo must be based on a unique timestamp. > > > That's not really an absolute...Having a system that generates > > always incrementing timestamps locally doesn't address files from > > other sources. > > Let's call this the "relativistic" problem. Locally, we can trust > that clocks are uniformly increasing. But for far-away clocks we can > imagine that there times are not really comparable. > > But how likely is this? You, Terry, save a .leo file at home, then go > to work and save the same (or another) .leo file and ooooooops, the > two files are based on the same time stamp. > > For my money, that case has *zero* chance of happening, not 1%, not > 0.1%, not 0.00001%. Zero. > > And here are where id's come in. Certainly two *different* people > could have colliding timestamps, no matter how far away, but unless > their id's also collide there is, in principle, no chance of their > separate .leo files colliding. > > In short, the combination of id + timestamp really must *never* (zero > percent) collide. Otherwise Leo is broken and we must use another > scheme, maybe uuids. > > In the past, we thought the probability was effectively zero. Now, we > know that Bob's edge case exists. But Bob has helpfully restored the > absolute nature of this requirement by adjusting timestamps so the > *never* collide. So for me, Bob's fix is absolute. > > > I'm not seeing how the file number lets me know that the gnx > > > > tbrown.20141015060623.1234.6 does not already exist in the .leo file > > being read, particularly when the .leo file was created on another > > system. > > It doesn't. Right now I don't see why the file numbers are needed, > or useful. > > Actually, given that every "base" timestamp is unique, I don't see why > the post scan is needed either. But then I got up at 2:30 am :-) > > Given that every invocation of Leo has a (locally) unique timestamp, > can somebody please explain how *any* kind of collision can happen? > Thanks. My brother Tim in New Zealand sends me a .leo file. Current time comparison: Chicago 10:48 am Wednesday Auckland 4:48 am Thursday Depending on daylight savings time, there's a 17-18 hour window in which I have what seems to me to be a 1/(17*60*60) chance of choosing a timestamp that already exists in the .leo file. Also, Tim's id happens to be tbrown too, damn it :-) If we switch the timestamp to GMT instead of local, I know my some of my personal tools would break, so let's not even go there :-) No, I don't have a brother in NZ called Tim, but usernames do repeat a lot. It looks to me like UMN's username index part has past 10,000 for Andersons, i.e. andeXXXX has stopped working and they've been forced to go to andXXXXX. Imagine how many jandersons that is in cases where people go to pick their own username on a local machine :-) I'm speaking with the advantage of complete ignorance of the read code, but to my mind the pattern: - start of read code - pick timestamp, gnx prefix for new gnxs in this file will be tbrown.20141014103456. - while reading file, take note of the maximum index on any gnxs seen with that prefix. - when creating new gnxs, start from an index value higher than that maximum There seems to be zero chance of accidentally generating a gnx that already exists in the file. But, perhaps the above is naively simplistic, I can see that if there's a need to start assigning gnxs before all the reading / seeing of existing gnxs is done, that's a problem. A possible solution, given how unlikely encountering gnxs with the duplicitous prefix is, would be to proceed as above, and in those incredibly rare cases, re-do the load armed with the new safe maximum index value + 1. Cheers -Terry > Edward > -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
