Martin Wirblat <sql.mawi at t-link.de> wrote:
> Hi Göran,
> 
> >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. 
> 
> In a system where packageName+versionNumber is unique you can say 

I assume you then want packageName to be immutable?

> something like versionNumber >= x for the dependency system. Isn't 
> this much more simple than to supply a list of UUIDs, which has to be 
> updated every time a new version of a prerequisite arrives? 

"updated every time a new version of a prereq arrives" ??

Personally i want the dependency system to describe "verified working
configurations" and nothing more. Rules like "any version later than x"
are IMHO not so good.

Instead I want to have the ability to register *multiple* such "verified
working configurations" and associate them with a PackageRelease. Such a
config simply says that PackageRelease X works if you have
PackageRelease y and PackageRelease z installed. Since PackageReleases
also have UUIDs that is what these configs have internally.

If it turns out this config was wrong - then you change it. There are no
versions of configs. If you discover another working config then you
publish that one too.

And when you release a new version of the package (a new PackageRelease)
then you will simply need to reverify those configurations and if they
work you can simply "copy" them to the new PackageRelease.

> I would think we will need to deal with, or to type or to read the 
> reference much more often than we may think now. 

Again, I am only using UUIDs internally in SM. And they are only used to
"connect objects together again" when things are turned into textual
descriptions and then comes back into the model. It is simply *an
external representation of the object references*.

> For instance if we later decide to have 'sort of name spaces' created 
> during filein, with prefixing globalNames with packageNames ( i.e. 
> PackageName_GlobalName ) we may end up coding with these references. I 
> think such 'name spaces' are an interesting alternative to real name 
> spaces, they are fitting to the philosophy of assembling together a 
> special image with load scripts, and we should have this option for 
> the future.

I agree. I am all for "simple" solutions like for example "prefix" based
namespaces. I have been planning to introduce "Person" in SM which could
mean that we can have entries for developers. We could add signing etc
and keep the developer "sig" in there too. Having that it would be
trivial to start using the "sig" as a prefix/suffic to get guaranteed
unique names:

SharedStreams-gh

BUT... they would still need to be immutable to really replace UUIDs.
And when we start using names as references then perhaps long names with
many words and spaces will make it hard. For example, what is the name
of the package loader? Do you know without looking? It is "SM Package
Loader". I bet you didn't remember the SM part.

But let's play with the thought - we simply demand shorter names that
people can remember. If we add the "sig" thing as a simple namespace
thing - how could we make the names mutable and still have the old names
work? One solution would be to let a package have an OrderedCollection
of names. It simply remembers the old names it had before. If all those
names are unique within the "sig" (we will need to enforce that) then we
would be ok.

> Furthermore we need to talk about packages, and we will not reference 
> them by UUID, we will use their names and versions. 
> 
> The notion of packageName+versionNumber has more information than a 
> quasi-random number. 

True.
 
> To make things easier package names should be unique ( which you said 
> is assured already ) and they should NOT be changed. But if for some 

Well, it is assured - but ony because the system is centralized today.
You can only publish a package using the web UI at the master server.
The plan is for people to be able to do that distributed.

> reason it is seen appropriate, you can change a name. Assuming that 
> you supply a new version of the package too, the name+version notion 
> will be more simple than UUID's: 

Ok, so you are simply saying that the name could be put in
PackageRelease instead of in Package. Yep, I have been thinking along
that line too and at this point I would agree that this is simpler than
the OrderedCollection thing above.

> For the dependency system you will have at maximum the same overhead 
> as with creating a new UUID ( you will need a longer description of 
> allowed prerequisites for packages depending on the renamed one ). For 
> SqueakMap it is simply a new package, and if you want to be able to 
> track down the history of a package than the UUID version will need 
> equal or more overhead too. 
> 
> Given the two alternatives [name+version alone] and [name+version and 
> UUID] I think I vote for the former. If we really use name+version 
> sometimes and UUID some other times we are violating your beloved KISS.

Probably yes.

> Perhaps we can have something like packageName+buildNumber where 
> buildNumber is generated by SqueakMap and starts with and is 
> incremented by 1 to have even more KISS. 

We have that in fact. PackageRelease has a "autoVersion" in parallell
with an editable version String as today.

> The only reason I see for using UUID's is that they can be created 
> isolated and be guaranteed unique where unique names require somewhat 
> more to do, but I think this additional effort is dwarfed by the 
> advantages a unique packageName+buildNumber has. 

If we adopt a simple "sig" based namespace scheme then the problem with
creating them in isolation will also be solved.

I will write down a proposal on this. I think you have persuaded me.

> regards,
>     Martin

regards, Göran