On Wed, Oct 22, 2014 at 10:12 AM, 'Terry Brown' via leo-editor <leo-editor@googlegroups.com> wrote: > > TL;DR: re-instate Bob's timestamp fix in core, doesn't make sense to be > an off-by-default plug-in. UUID gnxs: wishlist priority, current time > vs. session start time timestamps would be nice though.
Thanks for this summary and all your thoughtful comments. Upon further reflection on my part, we are in almost total agreement. > Ok, so your different invocations just refers to the fact that the current > gnx is not guaranteed to be universally unique, and in the extremely rare > case where it clashes *and* someone uses paste retaining clones, stuff breaks. Correct. > I think Leo should be around for a long time to come, but I'm not sure it > will be around for the length of time it will take that to happen in the wild > :-) I agree. This fact makes Leo's job much easier. The singleton NodeIndices object, g.app.nodeIndices, can delay allocating gnx's until after each .leo file has been read. Furthermore, as you suggested several days ago, a bit more cleverness in NodeIndices class can eliminate the need for the post pass itself. At the end of the load process (for each .leo file) we just allocate the not-yet-allocated gnx's. This is simple and safe, with no downsides. > How is having to enable a plugin better than having to use a > '--no-duplicate-gnx' command line parameter? It's not. The unique_timestamps plugins was a wretched idea. It implicitly dissed Bob's work flow. This is a recipe for further problems for anyone who uses a similar work flow. Instead, everything should *just work* for everybody. > I think Bob's increasing timestamp fix should just be re-instated in core, I > can't see how it has any negative impact on anything. Happily, this is not needed now that we know that P1*...*P4 is so small. > I think [the uuid representation in sentinels] problem is unimportant I agree. > Also take the opportunity to switch to a current time, rather than > session start time, timestamp, that would be nice. It's on the list. It fits in well with coming changes to the NodeIndices class. This change might mask Bob's test, so I'll make this change only after the delayed gnx allocation has passed Bob's tests. > I'm still not sure exposing people's network addresses in Leo files is > ideal...So... ha, funny thing, UUIDs... not necessarily unique? Excellent. Let's forget all about uuid's :-) ===== Summary Leo can ignore the possibility of global gnx clashes. Delayed allocation of gnx's will replace the post pass. A unique_timestamps plugin would cause problems anyone who uses Leo as Bob does. There is nothing wrong with Bob's work flow! uuid's are not need now, and probably not ever. There will be no --uuid command line option and no change to Leo's sentinel lines. There is still plenty of time for comments, but I think it is safe to go ahead with the improved gnx allocation scheme discussed here. 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.
