goran.krampe at bluefish.se wrote:

>>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.
>

Can you speak a little more about how you intend to make it 
distributed?  I still say that each package needs a canonical URL that 
is name based and hierarchical.  Why?  Because if we're using UUIDs, the 
UUID alone is not enough to locate the package...so, when you say that 
today every package can be located by it's UUID, that's only because we 
all know that every package is registered in a central location.  So, if 
you want to really refer people to a package, you must specifiy the full 
URL...like:
 
  
http://map2.squeakfoundation.org/sm/package/2bbc04df-fc80-476d-9caa-6877fa938bc2

...and that's just awful.  My point here is that a package, is not 
really identified solely by it's UUID.  Instead, I'd like to strip away 
the unecessary details of where the package is physically located, and 
use a "clean" URL that is known to refer to a package and which has a 
very specific mechanism used to lookup the physical location of the 
package.  Something like:

    sqmap://SharedStreams

This would be a url that points to the current version of the 
SharedStreams package on SqueakMap.  The name "SharedStreams" would be a 
"top level" package domain.  Optionally, you could be allowed to name 
your package using a hierarchical domain like organization:

    sqmap://SharedStreams.gk

You only need to stake a claim to your initials (or whatever else), and 
you have your own name space for naming packages...in addition, such 
notation could eventually be used to distribute the database of package 
registrations.  For example, I could host a SqueakMap server that 
resolved all package names that were named like *.svp, and the fact that 
I am operating that package domain could be registered with the root 
SqueakMap server(s).

Lex mentioned that this was unnecessary because we can just mash all the 
package names from various SqueakMap servers together and have list of 
locations to search to resolve packages...this is fine, and doesn't 
conflict with a hierarchical naming scheme, both can coexist (in fact, 
that's how the DNS system works at its roots).  We can simply attach 
special meaning a "." in the name of a package that indicates "packages 
within this domain might actually be resolved using a different 
SqueakMap server."  If one or more dots are present in the name of  a 
package, the SqueakMap server may, or may not, defer resolution of that 
name to another server.

- Stephen