SM final tweaks (was Re: Trouble getting SqueakMap to work)
sql.mawi at t-link.de
Thu Jan 29 09:33:06 UTC 2004
Avi Bryant <avi at beta4.com> wrote on 29.01.2004 00:02:44:
>On Jan 28, 2004, at 2:32 PM, goran.krampe at bluefish.se wrote:
>> So the idea is to... add this "speaking UUID" as a field in
>> SMPackage? Which is generated when the package is registered I
>> First - this "speaking UUID" would still not make packages
>> renameable. Secondly - since this is so, the extra number at the
>> end is hardly necessary since SM actually enforces the package name
>> to be unique!
>> So actually - what does this mean? What would happen if we simply
>> used the package name (haven't looked at your code) with tricky
>> chars removed
>> as shown above and perhaps also changed into lowercase (are all
>> filesystems case sensitive?) and truncated at 31 chars?
>> Well, theoretically the removal of tricky chars/truncation etc could
>> make two packages end up with the same name.
>I think you're misunderstanding. Let me rephrase (my understanding
>of) the proposal:
>Currently, to generate a new unique ID for a package you use Squeak's
>UUID class, which basically gives you a large random number.
>What if, instead, you used a derivation of the original package name
>(whatever it is first registered with), truncated and with tricky
>characters removed, and with some extra numbers at the end to ensure
>This isn't a new field, or a new concept, or something that in any
>way changes any of the semantics of SM. It's simply a new algorithm
>for generating the UUID for a package that happens to have the nice
>property that a human, looking at a UUID, may be able to guess which
>package it belongs to (although in some cases, especially after
>package renames, they may not be able to guess with 100% certainty).
>This sounds like a pretty good idea to me.
Yes, exactly that is the idea, a new algorithm for generating a UUID -
the speaking UID.
Some thoughts about lower/uppercase:
I have written this method so that it generates both upper- and
lowercase. If for some reason it is necessary to resort to only one
of that, you can simply convert this UID with e.g. asLowercase. This
only moderately increases the probability of a name clash ( look at
comment of method ).
For SM it may be appropriate to do so at the 'very last moment', when
it comes to database storage or retrieval. The package itself would
have the full ( upper + lower case ) UID, path names of filessystems
The idea is that if there is an 'obscure communication channel', which
flattens the UID to say lowercase, SM is nonetheless able to tell
which package is associated with that UID, simply because it
registered it under UID asLowercase. The name clash probability would
be only somewhat increased, and the readability for humans preserved.
All modern filesystems I know of are preserving the capitalization
info, but some ( e.g. all Windows fs's ) do not use it. Internally
they convert names 'asLowercase'. A SM-cache on Windows would have a
higher name clash probability than one on UNIX, but both are happy
with mixed capitalization.
More information about the Squeak-dev