AIUUIDSuite production readyness.

[Doubl3]

Dear fellow developers,

I'm using the AIUUIDSuite from the SDK.

While this is a really neet little suite, the API reference manual states:

This suite is in an experimental state, it is not completely production-ready.

I see copyright 2017 in the header as well as Version 3, so I'm guessing its allready pretty stable.

But should I worry about something?

Any body with some experience with this suite?

Thx in advance!

[A. Patterson · Accepted solution]

Our plugin is one of the reasons that functionality got added so we've been closely involved with it from the get go. That may have been left initially because there were a bunch of bugs and oversights that had to be remedied. I can say that we've been using this in production for over a year. 

[Doubl3]

Thx for the anwer, it gave me confidence to use the suite.

While using uuid's with my project, I'm trying to use them in a different way.

I figurred out that the uuid itself is a char[16] and it could be converted to an int32_t as follows:

int32_t idInt = id.mData[0] + id.mData[1] * 256 + id.mData[2] * 256 * 256 + id.mData[3] * 256 * 256 * 256;

I also noticed that uuid's begin rather low like in the hundreds and increase uppon add or delete.

Is it save to make the following assumption? :

The conversion to int32_t and so its value will stay rather lowish (below a million...) and thus will never overflow? I know it will probably allraeady overflow at  id.mData[3] = 128 but like I presume will not happen...?

Even   id.mData[3]*256*256*256 seem to much extra calculation. 

What is your experience?

[A. Patterson]

We never look too closely at the values, just accept that they're unique and use them as tokens. I don't know how much I'd depend on any apparent pattern to their allocated value -- I presume they're using a UUID generator, and who knows when (or if) they might swap one out for another.

[Doubl3]

I've noticed that when creating a path art object with the rectangle or ellipse tool the UUID keeps on changing till you let go of the left mouse button when done creating the shape. This propably has to do with the way those tools are coded... creating and deleting till the tool has a mouse up... I don't like that. 🙂  Also when one deletes a segpoint from a path art object the uuid is again swapped with a new one... this again makes it pretty useless for applications where one really needs a unique ID for the livetime of the session and/or object. So it is unique in the sense that it is the only object with that ID but it changes in some situations when, in my opnion, it shouldn't... Basicly there is no watertight system of uniquely identifiable objects for lifetime of session or object... unless I'm overlooking something... ?

[A. Patterson]

It's less an issue with UUID then the way those tools are coded. I've known for a long time that several path releated tools do silly things like create whole new paths rather than edit existing ones. At least with the UUID system you can kind of follow the chain of changes, but not easily.

You could take a look at AISafeArtHandle. I can't remember if that one will survive path edits or not. That's basically an AIArtHandle that you can safely rely on for the life of the document -- not beyond though. It may suffer from the same problems w.r.t. path tools though, I don't think I've ever tested that.