generateUUID

[splash21]

To solve immediate requirements for VCS, version 4 UUIDs do what you need and are trivial to generate. You could even include optional namespace parameters and include them in the random generation.

[LCMark]

Open Language won't 'do away with functions' - you'll still be able to define them if you wish. However, the reason things are functions at the moment is that (in many cases) they were easier to add like that rather than as nicer English-like syntax. When we clean up the current language syntax as much as possible English-like expressions will be preferred over function call syntax - after all, LiveCode is meant to be an English-like language.

My suggestion for syntax above was as an expression (throwing out future ideas here - i.e. after Open Language - not sure how feasible the 'a new uuid' form would be to implement currently):

Code: Select all

  put a new uuid into tUUID -- version 4
  put a new random uuid into tUUID -- version 4
  put a new md5 uuid from "com_runrev" -- version 3
  put a new sha1 uuid from "com_runrev" -- version 5

One could get lost in the possibilities for syntax but the most important thing first of all is to work out what functionality is needed and how it is to be implemented

In terms of libraries then the boost ones come with the requirement for the whole 'boost' thing which is not something that I would want to see required by the core engine as it does put hefty requirements on compilers and coders C++ knowledge. The engine essentially uses C++ as a better C for the most part, with the convenience of virtual functions and templates used sparingly (it doesn't use exceptions nor RTTI - which most C++ libraries rely upon).

So the choices seem to be one of use libuuid from util-linux or ossp; or alternatively roll our own. It seems that OSSP comes with a suitable prng implementation for Windows - which it might even be wise to crib to replace the 'randomBytes()' function implementation with; thus removing that function's dependence on the revsecurity blob. Ideally we wouldn't need a separate library compile for this - the code for uuid generation seems pretty stable and small, so could be cribbed into the engine just like the md5 and sha1 code is. Android, iOS, Windows and Mac I'd be tempted to stick with system functions if possible - and if they can generate all the types we want.

[mwieder]

I'm not sure I like "a new" whatever... "a" isn't a definite article and it sounds too much like an anonymous function, i.e., "any new" whatever.

...althought "put any new" might be a synonym for "put a random new"...

[monte]

OK, so it sounds like for now it should be implemented as a function.

It occurs to me that most uuid implementations will also have md5 and sha1 and there's probably no point replicating that in the engine either... ossp also could give us a mac address function and ui128_t could be the basis of the UUID/ID changes I've been banging on about.... so perhaps this whole thing has much broader scope than I was thinking.

Is there any big advantage to using platform specific code if this library is portable enough and can be used for multiple features?

[monte]

Hmm.. ossp includes unistd.h so maybe the pnrg implementation won't help us. Can you static link to libraries compiled against MinGW? I know you can dynamic link because I usually find this easier with externals.

[LCMark]

I hadn't looked at the library in any depth - I just noticed they had some code for PRNG for Windows that we could potentially crib that's all (not use directly from the library).

All code that is integrated into the engine has to compile with the currently used toolchains for it (i.e. Visual C on Windows), so anything that requires MinGW on Windows isn't something we can use. Indeed, if the library is too unixy and won't compile out of the box on Windows, then it makes it one that we can't realistically use. [ Although this doesn't mean we can't crib the code we need, modified appropriately to compile within the engine source tree - the sha1 and bsdiff stuff is an example of this ].

The reason for using system provided functions if at all possible is that it reduces the need to link to extra libraries (and thus maintain the build side of things for them) and also reduces the footprint of the engine.

The way we usually handle things like this is to create an API that the platform-independent code uses, and then implement as appropriate on each of the platforms. So, in this case, something like:
struct MCUuid;

// Potentially platform dependent
bool MCUuidGenerateRandom(MCUuid& r_uuid_string);
bool MCUuidGenerateMD5(const char *namespace, MCUuid& r_uuid_string);
bool MCUuidGenerateSHA1(const char *namespace, MCUuid& r_uuid_string);

// Platform-independent
bool MCUuidToString(const MCUuid& uuid, char*& r_string);

This way the underlying implementation can change without having to change the calling code.

[ MCRegion is a good example of this ]

[monte]

Looks like both CFUUIDCreate and CoCreateGuid are type 1 UUID while libuuid generate_uuid will try to create a type 4 using /dev/urandom and then fall back to type 1 if that fails. CFUUIDCreate would do iOS too I guess. If we prefer type 4 then we would need to use [NSUUID UUID]. java.util.UUID can do type 3 and 4... looks like it can get the timestamp from type 1 UUIDs but not create them...

It would be nice if all platforms did random uuid but I'm starting to think either type 1 or 4 would be sufficient as long as we have something. In the end if you want a primary key for a database generated off a namespace then you could use sha1: get binaryDecode("h*",sha1Digest("hello"),tSha1) ... which can also be fairly easily turned into an actual type 5 uuid.

[mwieder]

Looking ahead to the engine's agnostic use of uuids / ids, I see that object ids are declared as uint4, so these references will have to be changed to support the 128-bit uuids.

[monte]

Yes, fairly significant change

Probably need to be implemented as a struct

There's only 76 references to obj_id but I imagine there's quite a bit more work than just changing those...

[LCMark]

I was thinking of making adding a uuid generation function an example to reference in the engine workshops at the conference - it covers a few areas quite neatly... In particular, syntax and platform-abstraction. It's also something of real use, rather than just a paedagogic example. Thoughts?

[monte]

Sounds good to me. I'd also like to get a grasp on how to add a command too.

[mwieder]

That makes sense to me, too. You may have to spend some time at the beginning explaining what a uuid is, though
but I think that would be a great example exercise to get things rolling.

[LCMark]

Good good

I've just spent most of the afternoon implementing a 'uuid()' function (my preferred English-like syntax not being possible with the current ad-hoc parser ) that can generate random, md5 and sha1 uuids.

Of course, I just tested it out and 'put uuid()' in the message box gave me the error 'uuid: not enough randomness available' which amused me for some reason - a little bit more debugging needed I think...

[mwieder]

I can haz random?

http://nonsense.sourceforge.net/

[mwieder]

Time-based and MAC-based uuids should probably easily be variants on the random uuids.
And do we need md5? I thought the md5-based uuids were deprecated.