package universes and filters question

Stephan Rudlof sr at evolgo.de
Sun Aug 8 17:42:03 UTC 2004


lex at cc.gatech.edu wrote:
> Stephan Rudlof <sr at evolgo.de> wrote:
> 
>>lex at cc.gatech.edu wrote:
>>
>>>Yes, I agree that you could get the dependency resolution to work the
>>>same here.  You can indeed implement a universe as a filter over a
>>>catalog of everything, if you are careful.
>>
>>>It does lead to some complications, though.  
> 
> [...]
> 
>>In spite of this I don't see a problem here.
>>Packages exist in different releases/versions.
>>
>>Normally, I think, one release of "Base" exists in just one universe:
>>eg. "Base_4.1.2.3" in just universe U_1; having a label #U_1 for the filter.
>>
>>Now to the more complicated case of a package release (one version of a
>>package) belonging to *two* universes: then you just have two labels,
>>say #(#U_1 #U_2) to flag this release as belonging two two universes.
>>The filters have to be written to deal with collections of labels, of
>>course.
> 
> 

> I agree that this could work, once some details are fleshed out.  I am
> simply saying it is more complicated.

It is just introducing 'universes' at one map.
Dealing with multiple maps just to separate universes gives other
problems (Göran has written about this topic).

> 
> 
> 
> 
>>>It also does not give you the decentralization properties that the 2-day
>>>universes prototype gives you.  It does not, for example, allow Disney
>>>to have a private server for Fantasia 2007 stuff.
>>
>>Why not?
>>
>>Assumed there is one main server and two local ones:
>>
>>main
>>
>>local1  local2
>>[etc.]
> 
> 
> Yes, but this is an extra feature beyond what you described above.  Note
> my wording carefuly: it does not *give* you the decentralization
> properties in itself.

I've focused at the privay point here: if I've correctly understood
Göran, he is planning to take this into account by the planned tree
structure.

> 
> If you are willing to have multiple servers, then I see no advantage to
> the design you described with #U_1 labels, etc.  Once you allow multiple
> servers, you can set things up like this:
> 
> 	main-3.4-stable   main-3.6-stable    main-devel  tweak-devel

You always can do this in one map: but you know this.

> 
> 
> Now there's no need for the stuff you describe about packages having
> multiple names, descriptions, dependencies, etc.   You can use simple
> package descriptions.  If different universes want a minor change to the
> package description, then you simply post a slightly different package
> descriptions to each server.

To 'package descriptions'. I had written (to the Disney private server
point, see above):

* Why not?
*
* Assumed there is one main server and two local ones:
*
* main
*
* local1  local2
*
* . The main one is parent of both local1 and local2.
* Then you just need a possibility to build a union of local packages
* belonging to local1 and local2 and the packages of main, and afterwards
* you are running the filter. This could be accomplished by downloading
* the package descriptions of main to the locals and adding the local
* package descriptions to them (e.g.) before filtering according the
* attributes.
*
* Where is the problem?

Here 'adding the local package descriptions' means adding information
about local packages (all information needed for installation!) residing
at a local server.


Greetings
Stephan

> 
> 
> 
> 
> -Lex
> 
> 

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3



More information about the Squeak-dev mailing list