Rugged ID

[LCMark]

Which corner? I think runrevmark is still resistant

I'm resistant to changing the id property to be a uuid because I think it is the wrong path and I think there is a better way - i.e. one where most of the time developers don't need to worry about id's at all and can refer to objects using opaque handles that 'just work'. Remember that the main impetus for uuid's being suggested as a replacement was a solution to a VCS problem (which they do solve admirably) - and while they might solve other problems too, opaque handles would be a higher level way to do so and provide provision for supporting VCS too. Of course, this means I need to find time to adequately explain what I mean by 'opaque handles'...

[mwieder]

Hmmm... I thought this was just a matter of locating all the id references in the engine and replacing them with uuid references. It seems to me that uuids are "opaque" enough. Note that for cloning purposes uuids need to be modifiable at a script level.

But the other purpose for uuids, besides version control, is to eliminate the problems inherent with current ids. For example,
The engine could refer to a stack's uuid instead of its short name to eliminate stack conflicts
Behavior references would survive renaming, etc.
Icons referenced by uuid would be more robust that the current mechanism using id.

[LCMark]

Hmmm... I thought this was just a matter of locating all the id references in the engine and replacing them with uuid references. It seems to me that uuids are "opaque" enough. Note that for cloning purposes uuids need to be modifiable at a script level.

Right - but just because we could do that it doesn't mean it is the best solution either implementation-wise or for the language / framework as a whole. Before embarking on such an endeavour evaluating other options would seem prudent (particularly ones which can still provide a UUID for VCS purposes)...

[mwieder]

<grumble...> ok - so the fact that we have a solution that enables version control, eliminates stack naming conflicts, allows us to uniquely identify objects and reference them independently of their location in a stack, and allows us to avoid the intermediate step of legitimating rugged ids... isn't good enough because "maybe we can think of something better"? I'm starting to wonder how much of this is just a "I don't really like uuids" bias. Maybe it's time to explain what you do mean by "opaque"...

[LCMark]

I perhaps shouldn't have 'bitten' on this quite so much until I could 'put my money where my mouth is' so to speak (and perhaps not quite so perjoratively - I apologise for that - it's been a loooong day!)

Give me some time and I'll write up my opaque handle idea so appropriate compare-and-contrast can be performed.

[mwieder]

I didn't think it was pejorative, I just thought the issue was settled, and I find myself surprised that you have second thoughts about it. No problem waiting for you to get your thoughts in order - I'll be curious to see what you're thinking here, since I did think uuids solved a lot of problems and haven't seen any other suggestions.

If we're not going to get uuids or some other opaque method of unique identification, then formalizing rugged ids does seem like a prudent way to go, but I'd rather avoid that intermediate step and put a robust mechanism in place.

[monte]

There is some disscussion of some other type of object reference here http://forums.runrev.com/viewtopic.php? ... 7&start=30

I can't quite grasp what is being suggested though...

[mwieder]

Yeah, I remember that (sigh...this is the third thread now where we're talking about implementing uuids), but I thought the (dangling) discussion was more or less resolved as "uuids do all this and more". I'm sure runrevmark has thought of some drawbacks to implementing id references as uuids that haven't occurred to me, so I'll await further word from on high.

[mwieder]

Bumping this to raise it for runrevmark's visibility.

It seems to me that if we can get the issue of replacing ids with uuids or <fill in the blank other opaque notation> then the issues Monte just raised of icon id resolution and the suggestion of "_internal resolve" would both be solved and we could move on.

I'm sure there are valid reasons for needing to wait and think about this, but I don't know what they are, and I think not being able to coalesce around a standard way to resolve unique identifiers is causing us to have to come up with alternate interim solutions.

So... Bump. Over to you, rrm.

[monte]

I'm not all that stressed about alternative interim solutions if they are _internal commands and not overly complicated...

My gut feeling is we won't see a real resolution to this issue for quite some time. Even moving to my original proposal of upgrading id to a 128 bit integer and allowing representation either way with a uuid struct under the hood I think would take some time. I think that may have been less involved than the general impression I get from some of the things @runrevmark has suggested although I don't have a handle on what he's suggesting just yet... perhaps it is simpler?

BTW the id resolution one was more general... It seems to me that the stackFiles property should be involved here somewhere because an image id reference is more likely to have a relationship to the mainstack than not...

[mwieder]

Stackfiles. Yes, you're right. I keep forgetting about stackfiles.

Re: the id stuff, "simpler" would be good, but I have yet to see or think up anything cleaner and more elegant than uuids.
I'd rather not have to go through an interim solution and the a "real" solution later on, because it would mean either maintaining both for backward compatibility or a wholesale replacement of the interim solution.

[monte]

You want lcVCS to be backward compatible? I'm about to start re-writing it with 6.1 only features That's why I fixed the properties and added a few other features after all...

Or do you mean the files generated with it? They are currently backwards compatible. Hmm... there's a point... saving as a stackFileVersion < the version uuids were implemented in would require assigning 32 bit integers to IDs that had bigger numbers... rats... that could be a big issue. Just when you think you've thought of everything...

[rkriesel]

... don't have a handle on what he's suggesting just yet... perhaps it is simpler?

Maybe expanding the altID to 128 bits, and repurposing it, would be simpler, and good enough until a future rework of whatever internals touch object ids.

-- Dick

[monte]

Perhaps in the end it really is better to just do this export/import translation and just add features to the engine to support it? Rather than a custom property it could be a regular property and the ID management for copy paste and new objects could be done by the engine when the uuid is first requested. Perhaps even the map of uuid -> object could be in memory so access by uuid becomes very fast... I'm not sure... I do know that @runrevmark said he would elaborate when he had time and that we keep distracting him with things like mobile sockets so he's never able to find the time

@rkriesel I think it would be better to just create a separate property... who knows how altID is being used

[mwieder]

@Monte- LOL. I mean backward-compatible from here forward. If we implement some interim solution now then we're probably stuck with it. Even if it gets deprecated I don't see it going away, and then we've got at least two different formats. If we really *do* want an interim solution and then move to something more permanent later on, why not use uuids as ids for an interim thing?

@Dick - yeah, I'm with Monte on this. If anyone's currently using altID for anything it will mess them up, and if they're not then altID is just like any other custom property.