i would suggest adding support for the widely used RFC4122 Version 4 UUID, 
which is generated completely random. In lua a script for generating these is 
about 5 lines long, but because of several reasons I don't want to use lua in 
this use-case.

I would definitely not add add additional dependencies. The only thing required 
to generate such a UUID is a random number generator (which is already 
available) and some string-concatenation. Example code comes out with a quick 
GitHub search: https://gist.github.com/kvelakur/9069c9896577c3040030 . 

I think adding this feature would not require too much effort. 

@Willy, whats your opinion on this?

Best regards

On 05.09.19, 17:32, "li...@ltri.eu on behalf of Lukas Tribus" <li...@ltri.eu> 

    On Thu, Sep 5, 2019 at 4:58 PM Schimweg, Luca <luca.schim...@sap.com> wrote:
    > Hey again,
    > I tried to use rand, but when using it, my generation code for a UUID 
looks like this:
    > unique-id-format 
    > To be honest I think for a simple UUID, we should not be required to but 
such a complicated and long line into the config. Also, I think that the 
performance impact of such a line is much bigger than the generation of a UUID 
in plain C code. We could just create a ACL generator called uuid or something 
similar which would do the job. The config would get much clearer.
    > Any opinions to this? I would be willing to implement such a feature if 
the maintainers would be ready to merge it in general.
    Are you proposing to implement a RFC4122 compliant UUID?
    Which UUID version?
    Which dependencies would it require?
    I guess something RFC4122 compliant based on openssl for example would
    work. Adding chunks of fragile code nobody is gonna maintain or adding
    additional dependencies like libuuid - probably not.
    I suggest we wait for Willy's feedback, but I want to stress that this
    may not be as simple as 5 lines of standalone C code ... we certainly
    don't want to act like we are generating standard compliant RFC4122
    UUIDs when that is not really the case.

Reply via email to