goran.krampe at bluefish.se wrote:

>"Andreas Raab" <andreas.raab at gmx.de> wrote:
>  
>
>>>>When you 'ultimately' dereference a package you do it by 
>>>>UUID. However, there are only very few places where this
>>>>is required. For everything 'inbetween' you should use 
>>>>'real objects' (PackageReferences) which allow
>>>>you to think in whatever way is more convenient to you.
>>>>        
>>>>
>>>Or to put it an other way (provided I understood you correctly) - we
>>>should use objects as "far" as possible and not rely on textual
>>>descriptions.
>>>      
>>>
>>Not quite. My point is that even when we write tools we are 'users'. If the
>>systems makes it hard for us to get to convenient notions (names) then it's
>>going to be a pain (and that's what Lex referred to). If names/ids are
>>properly encapsulated this is much less of a hazzle.
>>    
>>
>
>Ok, I am obviously not seeing the light here. It seems to me there are
>two possible scenarios, either you are using a tool that is "package
>aware" and it can then simply let you choose a package/packagerelease
>from a proper list. No UUIDs need to ever be viewed nor entered (and
>that was what I meant).
>
>...OR you don't have a "package aware UI" and then you may need to refer
>to something textually - in that case it is nice if you can use
>different means as long as you are aware of what you ar doing. Just
>using a name will possibly not be reliable in the long run. Using the
>UUID will be. Sometimes it doesn't matter and sometimes it really does -
>like when describing dependencies. When it comes to dependencies I would
>argue strongly for using UUIDs if it ever will be NEEDED to do it
>textually. But still, I am arguing that tools should be available that
>makes this unnecessary.
>
>For example, referring to a package with a UUID-based URL (and
>definitely not by using marvin.bluefish.se:8000 etc) like this is pretty
>persistent:
>
>http://map2.squeakfoundation.org/sm/package/2bbc04df-fc80-476d-9caa-6877
>fa938bc2
>
>While this is not as persistent:
>http://map2.squeakfoundation.org/sm/packagebyname/sharedstreams
>
>...but since we aren't describing dependencies it isn't as vital. Btw, I
>have taken the approach of letting the name of the Package stay in the
>Package object (and not have it in the PackageRelease objects). This
>means that a package can change name but it will - at any given time -
>have exactly one name. And any old name is forgotten.
>
>  
>
>>Cheers,
>>  - Andreas
>>    
>>
>
>regards, Göran
>
>PS. And of course the examples with the URLs had nothing to do with the
>representation of dependencies.
>

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, 
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 
orthogonal hierarchical naming scheme for packages...each name would get 
resolved to some SqueakMap server and package UUID.  I did something 
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 
a hierarchical structure to the names, we can eventually distribute the 
database that maps those names to actual packages.  I would envision 
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).

- Stephen