Open e-backmark-ericsson opened 4 years ago
Don't know if it helps, but in REMReM at least the generation of meta.id is made with help of java.util.UUID
library. In the below method (copied from remrem-semantics) it seems UUID Version 4 (random / pseudo random) is used.
public Meta generateMeta(Meta meta) {
// The event epoch time is generated in UTC format
meta.setTime(Instant.now(Clock.systemUTC()).toEpochMilli());
meta.setId(UUID.randomUUID().toString());
return meta;
}
I don't think it is crucial that the UUID version used is version 4, but it needs to fulfill this format specification: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, meaning that two of the hex digits cannot be just any digit, but needs to conform to a 'versioned' UUID. Taken from: https://en.wikipedia.org/wiki/Universally_unique_identifier#Format
And it would probably be a good recommendation to use UUID version 4
The current JSON schema allow version 1-5 but we could restrict it to version 4 if we want. See this file for an example of generating the UUID with version 4. https://github.com/eiffel-community/eiffel/blob/3c774286726d10bebc284b7fe6792ad204689589/examples/reference-data-sets/default/generator.py#L29
Description
The protocol documentation is not clear enough about what constraints there are on the UUIDs to be used as event ids.
Motivation
If kept as today there is a risk that event sending clients don't fulfill the UUID requirements. Of course the clients should validate events to send, but in case such validation is lacking the documentation should be clear enough.
Exemplification
One way could be to state the regexp used in the JSON schemas as part of the documentation. Even better would be to state that the UUID need to be 'versioned', what UUID versions are supported, and maybe other restrictions if possible to document.
Benefits
Less risk of clients sending events not conforming to the protocol.
Possible Drawbacks
None