I can do the integration too, but I need some people to say go ahead. I vote for replacing everything, there is no need for a plugin.
> On 09 Feb 2016, at 09:25, Guille Polito <guillermopol...@gmail.com> wrote: > > Sven, just to answer your last question. The UUID generation right now > generates the UUID fields like this: > > UUIDGenerator>>generateFieldsVersion4 > > timeLow := self generateRandomBitsOfLength: 32. > timeMid := self generateRandomBitsOfLength: 16. > timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength: 12). > clockSeqHiAndReserved := 16r80 bitOr: (self generateRandomBitsOfLength: 6). > clockSeqLow := self generateRandomBitsOfLength: 8. > node := self generateRandomBitsOfLength: 48. > > So... It's basically completely random. There is no part of the UUID that is > actually based on the node, the clock or the time. It is actually a random > string of bits that are generated using a number from /dev/urandom as seed > (in linux). > > Does the mac VM include the plugin? (I do not have a mac any more to test > fast ^^) > > I'll work on the integration of NeoUUID now, I hope this is the kind of > issues that got integrated in code-freeze :) > > Guille > > On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote: >> Here is a new version, in preparation of possible integration in the main >> image: >> >> === >> Name: Neo-UUID-SvenVanCaekenberghe.2 >> Author: SvenVanCaekenberghe >> Time: 8 February 2016, 8:33:04.141334 pm >> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e >> Ancestors: Neo-UUID-SvenVanCaekenberghe.1 >> >> Streamline UUID generation >> >> Add a current, shared instance >> >> Added better class and method comments >> >> Add more tests >> >> As suggested by Henrik Johansen, change to a version 0 UUID to indicate that >> we follow a custom approach >> === >> >> The class comments now reads as follows: >> >> === >> I am NeoUUIDGenerator, I generate UUIDs. >> >> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number >> that can be used for identification purposes. Concretely, a UUID is a 16 >> element byte array. >> >> The intent of UUIDs is to enable distributed systems to uniquely identify >> information without significant central coordination. In this context the >> word unique should be taken to mean "practically unique" rather than >> "guaranteed unique". >> I generate UUIDs similar, in spirit, to those defined in RFC4122, though I >> use version 0 to indicate that I follow none of the defined versions. This >> does not matter much, if at all, in practice. >> >> I try to conform to the following aspects: >> - each 'node' (machine, image, instance) should generate unique UUIDs >> - even when generating UUIDs at a very fast rate, they should remain unique >> - be fast and efficient >> >> To achieve this goal, I >> - take several aspects into account to generate a unique node ID >> - combine a clock, a counter and some random bits >> - hold a state, protected for multi user access >> >> I can generate about 500K UUIDs per second. >> >> Implementation: >> >> Although a UUID should be seen as totally opaque, here is the concrete way I >> generate one: >> - the first 8 bytes are the millisecond clock value with the smallest >> quantity first; this means that the later of these 8 bytes will be identical >> when generated with small(er) timespans; within the same millisecond, the >> full first 8 bytes will be identical >> - the next 2 bytes represent a counter with safe overflow, held as protected >> state inside me; after 2*16 this value will repeat; the counter initalizes >> with a random value >> - the next 2 bytes are simply random, based on the system PRNG, Random >> - the final 4 bytes represent the node ID; the node ID is unique per >> instance of me, across OS environments where the image might run; the node >> ID is the MD5 hash of a string that is the concatenation of several elements >> (see #computeNodeIdentifier) >> Some bits are set to some predefined value, to indicate the variant and >> version (see #setVariantAndVersion:) >> >> Usage: >> >> NeoUUIDGenerator next. >> NeoUUIDGenerator current next. >> NeoUUIDGenerator new next. >> >> Sharing an instance is more efficient and correct. >> Instances should be reset whenever the image comes up. >> >> See also: >> >> http://en.wikipedia.org/wiki/UUID >> https://tools.ietf.org/html/rfc4122 >> === >> >> If we integrate this, I think we should replace the old generator and the >> use of the primitive/plugin. But that requires at least some support apart >> from me. >> >> And although I think that we should integrate this generator and get rid of >> the plugin, I think there is probably an underlying problem here (why did >> the generator fail ?) that could be important to find. >> >> Sven >> >>> On 08 Feb 2016, at 10:38, Henrik Johansen <henrik.s.johan...@veloxit.no> >>> wrote: >>> >>>> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <s...@stfx.eu> wrote: >>>> >>>>> 2) Misrepresenting the way the UUID was generated (a combination of node >>>>> identifier + timestamp + random value, similar to type 3, but with >>>>> differently sized/ordered fields) by marking it as being of type 4, which >>>>> is defined to be UUID consisting of random bytes. >>>>> IOW, I think it should be marked as type 0 instead of 4, so for the 1 >>>>> person in each country who might be found to assume something about the >>>>> implementation based on the type field, won't later feel he's been duped >>>>> when checking the generator. >>>> OK, I certainly want to change the type. Thing is, I cannot find a >>>> reference to type 0 anywhere that I am looking (I mostly used >>>> https://en.wikipedia.org/wiki/Universally_unique_identifier). Where did >>>> you find a definition of type 0 ? Or would that be a way to say 'no >>>> specific type' then ? >>> My rationale was that it is currently unassigned, and the least likely >>> number to be chosen as identifier by new versions of the standard. >>> IOW, for those who care, it might raise a "hmm, this is strange, better >>> check the source", upon which they will discover it is generated in a >>> non-standard fashion (but can verify for themselves it is generated in a >>> way still pretty much guaranteed to be unique), and the rest... well, they >>> can (most probably) keep on living happily without ever seeing a collision. >>> >>> Cheers, >>> Henry >> >
