Beside, you can't make slices ;-)
> On 09 Feb 2016, at 09:58, Sven Van Caekenberghe <[email protected]> wrote:
>
> 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 <[email protected]> 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 <[email protected]>
>>>> wrote:
>>>>
>>>>> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <[email protected]> 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
>>>
>>
>
