Hi Frank-- I wrote:
Right, there's no need for anyone to use UUIDs when referring to classes in Smalltalk expressions.
Torsten responded:
Yes, exactly this. We still use regular names for the classes - but for the tools they have a distinguishable ID. Best is to use a UUID for the ID as it is unique from the beginning. So if you create a class "Foo" and I create one both are unqique by ID - even when using the same name.
You responded to Torsten:
The problem I have with UUIDs is that...
Hooray! Discussion! :)
...in a distributed setting, you need to rely on everyone to generate UUIDs correctly. Now IF everyone implements UUID generation correctly...
This is not hard, if there are common implementations at the Smalltalk level (like we have common collection classes), or at the virtual machine level (like we have common plugins).
...and IF everyone plays the game in good faith...
Whoa, if you're going to invoke that concern, then I wonder how you can tolerate what we've already been doing. Namely: - Compiling source code with no way to trust its authorship. - Compiling source code with no way to trust that the code does what the authors say it does (trusting authorship would help somewhat). - Compiling source code with no way to trust that the target compilation environment is sufficiently like the one in which the source code was developed.
...you will almost certainly not get a UUID clash. But when you say your code depends on package/class/object/method with guid SOME_GUID, and I as a bad actor inject my own class with guid SOME_GUID, how are you to know that you've just been 0wned?
Again, how would you know today that the filein or Monticello package you just loaded has 0wned you? When would you know? What would you do about it? I think we have to concede that a motivated insider will always be able to do bad things for a while before being caught, probably involving social mechanisms. I'm interested in how to minimize this time, and how to undo the bad things. With the Naiad module system, I want to identify, as soon as possible, the human interactions required to establish trust, and facilitate them. Naiad modules are synchronized live between systems (without recompiling source code; only authors compile source code). You could know you're likely to be 0nwed if you proceed with a module synchronization because the cryptographic signature of a module is incorrect for its purported authors. It would be similar to knowing that the PGP-signed message you just read isn't really from the person whose key you verified earlier.
Wouldn't it be better, instead of using a key-value store (key K maps to value V), we have a store that uses function_of(V) maps to value V? Like in git: a commit is uniquely identified by its hash and, because the hash is a checksum, you can't - short of engineering a SHA-1 collision (good luck with that) - forge part of the system.
The things we want to identify have state that changes over time; their hashes would also change over time. This is fine for things like a module signature during a synchronization conversation (in fact, I'd like to leverage the actual existing public-key cryptography infrastructure for Naiad). It's inappropriate for referring to a changing class over the course of years. UUIDs are a straightforward and well-known way of generating IDs for things which change. Anyway, there it is, both UUIDs and hashing are involved. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)