SM final tweaks (was Re: Trouble getting SqueakMap to work)
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Thu Jan 29 08:36:33 UTC 2004
Avi Bryant <avi at beta4.com> wrote:
> 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.
We talked quite a lot about different approaches on IRC the other night
(for me). A few problems not even thouched yet:
1. Can we be sure that the URL filename is useable in the local
filesystem? (length, chars etc)
2. Do we need to be aware of limitations of filesystem directories -
like max number of entries? The current cache has as many directories in
sm/cache/packages as there are packages on SM.
3. Can we safely use dots in the autoversion directory name? Currently
we don't have branches but future may introduce them.
My stance so far in all this:
- I will keep the UUIDs no matter what. They are there as the definitive
fallback. They are unique. They are static. They don't imply anything
that can be confusing (which of course also is their problem but
- I will consider any SMFileCache implementation put forward that
*works*. In short, the discussion carried away far too long on IRC and
now I am pulling the brakes by saying "Put the code where your mouthes
are". You get my meaning. :)
- I don't want to introduce extra files swimming around that makes the
cache "non direct" introducing the need to scan the cache etc to get the
bearings. That is just silly IMHO.
One approach that I could live with is this (food for thought to the
people now grabbing their browsers and pointing it at class SMFileCache
- yeah, right):
1. When people register packages, make sure that the package name with
spaces and other tricky chars removed, all lower case, truncated to 31
chars is *unique*. If not, ask the user to pick another name. Also show
this id so that the user can see it.
2. If a package is renamed - regenerate the id.
3. Store the id as a new field alongside with the name and the UUID.
4. Use the id in the disk cache instead of the UUID.
5. If a package is renamed it will only lead to a cache miss and some
"litter" in the cache. We could whip up cleaning code if we wanted to
PS. The above assumes that 31 chars is the lowest limit we need to care
More information about the Squeak-dev