Hi all!

lex at cc.gatech.edu wrote:
> Stephan Rudlof <sr at evolgo.de> wrote:
> > Assumed there are separated universes for stable and unstable packages,
> > U_stable and U_unstable.
> > 
> > Now we put the union of these packages into a new universe U_all, but to
> > know, where they have come from, we label each package with the name of
> > the universe, from which it stems.
> > As a result each package in U_all has a label #U_stable or #U_unstable.
> > 
> > 
> > Now to my question:
> > 
> > I see no difference between the functionality of
> > - a dependency resolver working in U_stable (or U_unstable), and
> > - another one working in U_all *together* with a filter selecting the
> > wished packages with label #U_stable (or #U_unstable), before starting
> > to work.
> > 
> > Do you see any problems with this approach?
> 
> 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.  Suppose the "TweakBase"
> package wants to be called "Base" in the "Tweak" universe?  To make the
> name-shortening work, you need to either let packages have different
> names under different filters, or you need to make two separate entries
> for "TweakBase" and Base".  The former case is complicated, and the
> latter case seems to defeat whatever purpose there is of making
> universes be filters.

The above problem doesn't really sound like a big issue to me. Squeak
packages/projects tend to want to have unique names anyway - simply
because the Squeakers, we, would otherwise get confused. Implicitly
there is just one "namespace" for public Squeak packages.

For private "project maps" on the other hand I agree it might be useful
to be able to use context dependent generic names like "base", but
then... well. I do think it should be possible to have local servers
with private content - I haven't denied that. I just don't believe in
multiple public maps - especially not along these "axis" (stability etc)
which just as easily can be modelled as attributes on the objects in a
SINGLE model (single *model* ~= single *server*).

> 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.
> 
> By the way, here's a little thing to think about from the Debian world:
> few Debian package use the original upstream package bit-for-bit
> identically.  It frequently, at the least, installs files into different
> locations than the upstream "make install" would do.  If this happens in
> Squeak, and if we implement universes as filters over an underlying
> catalog of everything, then the catalog of everything will  fill up with
> thing like "Chuck for 3.7", "Chuck for Tweak", "Chuck for 3.6", etc.,
> which are all minor variations of each other.  That doesn't seem like an
> improvement over handling all the "for foo" variants in separate
> catalogs.

But if the (as you like to call it with a slight negative touch)
"catalog of everything" is indeed a catalog of EVERYTHING, then isn't
that exactly what you want? :)

Anyway, I don't consider this issue a real "issue" either. IMHO these
variants of a package are simple different branches of releases of it.

Now to my final more urgent meta question:

I am worried about this discussion. I briefly looked at the universe
code and noted that it in many ways it duplicates concepts etc from SM.
Now, I worry about "forking" in these fundamental architecture projects.
IMHO one of the greatest things with SM is that we have managed to stand
behind it in a united fashion and that it thus has become THE place to
look for stuff.

As I have said before - the whole idea with a catalog is diminished if
we have 10 different catalogs all scattered out and using different
tools. I really, really do think we should strive for focusing on ONE.
That is also why I am so intent on *collaboration* in developing SM.

This doesn't mean SM should not support private "Disney" catalogs etc,
what I mean is that:

- I think it would be better if we focused development efforts on SM.
- I think it would be better if there is a user experience of a single
catalog that people use.

So given the discussion I will contemplate how to be able to have
multiple "source" catalogs mixed and merged into the client including
the update/commitability I am striving for. It will very likely end up
with a whole range of questions about limitations - but I will try it,
without loosing the "sense" of SM being a singularity.

One thing for example is that if we DO make SM capable of this then
surely we would like SM to be able to keep track of all these other "sub
maps" so that I as a user isn't condemned into finding them "manually"
using Google. That would just put us right back where we were before SM.

So... in short: Lex - if you want to work on these issues would you
consider working with me on it in SM, or have you already decided to
"roll your own" and try to "compete" with SM?

It would be very good for me to know, and it would also be very good for
me to know what others think.

Also - I don't agree fully with Stephan on his model, but I still don't
want him to go off and roll his own. It is better to be able to
complement each other and work together. And to enable SM to be a base
for it.

> -Lex

regards, Göran