Hi Stephen!

Stephen Pair <stephen at pairhome.net> wrote:
> 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 

I don't agree. The UUID is enough as I see it.

> 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 

Well, to be a little bit more subtle: It is because every package is
registered *in SM*. That wouldn't change with an SM that consists of
multiple servers. Just like DNS is "cenralized" even though it has tons
of slave servers.

> 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 

Of course it is awful! But that is not of much interest. I could just as
easily have given just the UUID and you would find the package in SM.

> really identified solely by it's UUID.  Instead, I'd like to strip away 

It is. Because there is and will be only ONE SqueakMap. But it will be
distributed over multiple servers instead of like today on just one
(well, plus all the clients today).

> 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

Perfect. We can adopt that, fine by me! 
 
> 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

That is what I am leaning towards, yes.
 
> 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).

EXACTLY.

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

Well, here I feel that you are perhaps making this a bit more
complicated than I would like. I would suggest a slightly simpler scheme
to begin with and then if people want to move over to what you describe
then fine.

My proposal is that SqueakMap is organized with one or a few master
servers. If we want to have more than one (mirror/failover kinda thingy)
we would need to add a bit of synchronization between them so that only
ONE at a time holds the supermaster "token". But that is a detail.

Then we allow people to setup slave servers. In fact, we all have one
slave server each as it is today! It is just that *today* it is strictly
readonly. A mirror of the master updated through numbered transactions.

I want to move into the direction when the slave servers aren't
readonly. I want you to be able to setup a slave server at your company
that you and your Squeaker-friends can use to register your packages.

That slave server mirrors the master SM server(s) and additionally
contains your packages (which aren't visible outside your company). When
you feel like publishing a package outside of your company you should
easily be able to do that and your slave server should contact the SM
master and "move" the package entry up to the master instead thus making
it visible for the rest of us.

The above could equally well work with more levels than described and it
would work exactly the same for a single personal computer - the map you
have locally would simply not be readonly anymore!

But the important fact here is that SM is still ONE ENTITY. The master
servers are known. And the map is *complete* just like today. You as
well as I know that we have 245 packages today. And if I give you a UUID
you can easily look it up - you don't need to know which server to go to
- just look in the map. Because there is just ONE map.

Sidenote: I am thinking about not having UUIDs but I need you guys to
help me figure out how the package cache etc should work etc. See my
other posts.
 
> - Stephen

regards, Göran