links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Rationale for the Virtual Module Hierarchy
Last updated at 2:35 pm UTC on 16 January 2006
Note: The goal that is described below (creating the illusion of one single repository by using a shared registry/database where the repositories and packages are registered) has been implemented in SqueakMap.

Les Tyrrell wrote:

> I would argue _slightly_ against what you are proposing here. I do agree that
> as far as the user is concerned, they should not be presented with a
> bewildering
> variety of places to go looking for bits and pieces of code. However, I would
> not want that to mean that there is literally only a single repository in
> existence- at least not in the sense of one server, sitting on one machine,
> for
> the entire planet.
> HOWEVER. I DO want it to feel like that is the case, in the sense that the
> user is presented the illusion of having rapid, unified access to everything
> ever written for Squeak ( or any other Smalltalk ) on the entire planet,
> sitting
> on their hard drive.

I think what Les is saying here is that there should not be a single, central repository, but a global, shared registry/database in which anyone can register their Squeak package and let this point to the actual repository.

You should be able to set up your own registry if you wish, like anyone should be able to set up their repository. There would just be a designated central registry. It would also need a scheme for structuring things. I think the Java/Internet domains scheme is ok, as others have said.

I think this is what Les meant because this is what I wanted to say ;-)

Hans-Martin Mosner wrote:

3. For server infrastructure, we need a way to uniquely name
independently created packages. The update server numbering schema does
not work here... I see two choices: My SCAN approach uses large random
numbers for IDs, minimizing the chance that collisions happen. This is
somewhat equivalent for M$'s scheme for globally unique ids. However,
SCAN by itself is probably not in a shape to be used here in such a
short timeframe. So here's the alternative: Use a hierarchical naming
scheme as in Java, reflected in corresponding directory structures. I am
no Java expert (actually, I'll have to wash my hands after typing that
dirty J-word two times in one letter...) but AFAIK a reasonable package
name under such a scheme would be /org/squeakland/andreas/graphics/b3d
or some variation with different separators. The details would need to
be fleshed out, but you can easily imagine having this as a directory
structure on servers. This would leverage the existing HTTP mechanisms
in Squeak, and existing mirroring and web serving software might be used
for server synchronization.