Squeak as Linux and other threads

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed May 21 08:29:54 UTC 2003


Stephen Pair <stephen at pairhome.net> wrote:
[BIG SNIP]
> I also don't really like using the UUIDs...I much prefer to refer to a 
> package by its name (it's much the same reason that I don't like using 
> IP addresses and prefer to use DNS names).  When a package is renamed, 

Well, I agree of course. But DNS names suffer from the same problem!
They simply aren't trustable for ever. The analogy isn't perfect but I
get your point and agree.

But still - if I never get to *see* or *type* a UUID then it is fine by
me if the dependency thingies use the UUIDs internally - I don't care.
Right?

> you should be able to leave some kind of forwarding info from the old 
> name to the new name.  I actually think that SqueakMap should have an 

Well, sure. But all this gets complicated quickly... forwarding,
resolving, reusing old names - where should I go then etc...

> orthogonal hierarchical naming scheme for packages...each name would get 

I agree. But SM was meant to be simple from the start. Thus a flat list
of packages with UUIDs. The names are ensured to be unique but you can
change them. I thought it seemed like a good simple compromise to start
with.

> resolved to some SqueakMap server and package UUID.  I did something 

Eh, to some SqueakMap server? Remember what SM is - it is not a repo.
Or are you somehow referring to my long term plans of being able to
structure the SM servers in a hierarchy etc? :-)

> like this to handle dependencies in KomPackaging, the registry is at 
> (this is my distributed hierarchical db ;)):
> 
>     http://squeaklab.org/PackageRegistry.txt
> 
> and package urls looke like "sqpkg://httpserver.kom:6.1"  (I can also 
> refer to SqueakMap packages using 
> "sqmap://PackageName:1.0")...basically, I want a name based way of 
> referring to packages and the contents within a package.  And, by using 

I agree - names are nice. But I still want them to be resolved to UUIDs
when entered and not when used. If I change a name then your references
will not work. If you had resolved them to their UUID when you entered
them you would be safe. To me it is simply a matter of internal
representation - internal=UUID, external/in a UI=names.

> a hierarchical structure to the names, we can eventually distribute the 
> database that maps those names to actual packages.  I would envision 

I would in that case simply have a "top domain" registry in SM. You
simply register your "mount point" in the namespace and then all your
packages will be below that mount point thus making sure they are unique
and also giving us some form of "browseability" hierarchically.

> using Urls to do lot's of things with packages...here are some examples:
> 
> sqpkg://httpserver.kom/name  "A friendlier version of the package name 
> (i.e. KomHttpServer in this case)"
> sqpkg://httpserver.kom/description  "A version independent description 
> of the package"
> sqpkg://httpserver.kom:6.1/description  "A version specific description 
> of the package"
> sqpkg://httpserver.kom:6.1/configs/default/prerequisites  "A list of the 
> prerequisite package urls for the default config"
> 
> ...etc...
> 
> Anyway, I'm sure if someone thought about it a little more, they could 
> come up with some improvements on this naming scheme.  But the bottom 
> line is that I'd like my primary way of referencing a package to be name 
> based *and* hierarchical (the hierarchical part is going to be necessary 
> if we are going to allow people to eventually host their own package 
> name domains).

I agree - we should move towards a hierarchy. It is simply a bit down on
the list right now.

I still though maintain the idea that we should rely on immutable ids
internally whenever we want to refer to something *and be sure it will
resolve forever*. I mean, come on - what else are UUIDs for? And I
repeat - in UIs or wherever we can have whatever cool and smart name
resolving techniques we like.

But when describing dependency models I would still use the UUIDs
internally. Or of course, when resolved in the SM model - the real
objects. The UI for describing the dependencies can use whatever they
like.

In short - if we start to have "name based" references INSIDE the SM
model (which IMHO this is - the dependency model should be inside SM
otherwise we will not be able to work with it) then we immediately need
to add a lot of smarts to make it work. It is simply not KISS anymore.

> - Stephen

regards, Göran



More information about the Squeak-dev mailing list