goran.krampe at bluefish.se wrote:
> > 2. My number one desire, which is not on your list, is to stop talking
> > about "the" map.  At the very least, there should be a map per version
> > of Squeak, because in practice packages in Squeak 3.6 are not going to
> > work in Squeak 3.0 unless you make at least a few changes.  Aside from
> > that, as soon as you allow multiple maps to exist at all, you make it
> > easy to think about clients pulling data from the union of multiple maps
> > on multiple servers.  In short, it seems like a lot of the features you
> > desire become simple if you allow multiple maps to exist per server, and
> > for clients to pull packages from multiple servers and/or maps.
> 
> I know you have been talking about this before - and my answer is still
> the same. :)
> I don't see why all those "maps" can live in one map. As they do now.
> 
> And I am not sure I see which features that would be simpler with
> separate maps.

Upgrading within a release stream would be simpler, with multiple maps.

Here's a scenario that absolutely requires multiple maps: I want to
tweak the standard distribution of Squeak to also include programs that
are specific to my organization.  I don't *want* my packages posted on
the public SqueakMap, and you guys don't want to be seeing my
org-specific packages much less the org-specific packages from thousands
of however many other people that are doing the same thing as me.

And finally, let me just mention that apt-get.org lists 674 unofficial
apt repositories.  People use this ability if you give it to them.  In
fact, Squeak itself is distributed via an unofficial apt repository.



> Note though that I have a slightly different architecture in mind for
> the future - a "tree" of servers where the clients are the leaves. But
> that has nothing to do with the axis of Squeak versions ,but rather with
> visibility of information (visible just for me, visible for my
> development team, visible for my company, visible for all in the world
> etc).

Yes, that's sounds similar, assuming you mean that each server can add
new packages to what its parent offers.  Note that the idea still works
even if the servers do not list a single parent -- they can list zero or
multiple ones.  And it even still works if the clients are doing the
final assemblage of lists of servers, plus you gain the ability to have
mix-in servers that can be added to multiple repositories.  And finally,
there is no particular need that there is one map per server, if you say
that *maps* are in a tree structure.

It seems like "have multiple maps, both on the servers and the clients"
is technically simple, fully general, and convenient.  The main thing
the trees approach seems to add is that clients now have to add the
parent maps to their list of sources.  However, in practice this is not
a problem: most repositories in Debian, at least, seem to be satellites
to one of the handful of "official" repositories.  Thus, users tennd to
have a source file like this:

	...official repository...
	...dvd software repository...
	...squeak repository...
	...java repository...
	...mozilla plugins repository, because the java repository breaks
them...

Automatic "parent" pointers would only remove a couple of these lines.

Granted, I notice that most repositories only seem to work if you use
them in conjunction with the intended parent repository.  Even then,
however, you might want to use a different mirror of that repository.


> > 5. I don't understand the issues you mention with synchronization, but I
> > see no need for SqueakMap to be messing with diff's.  If people want to
> > diff between versions then let them use the code development tools like
> > Monticello.
> 
> No, no - it wasn't diffs between packages. I was talking about how to
> synchronize what happens when 204 maintainers start modifying their own
> local maps instead of going through the single web master UI. *That* is
> not a trivial thing.

For performance, it is likely to be fine just to send the updates to the
master server.
  
And anyway, I still don't see where the synchronizing comes in.  It
sounds like you may be aiming for more reliability than is possible.  
If a thousand developers are posting updates all the time to a
catalogue, then there will be intermediate stages where people see
inconsistent packages no matter what you do.  This is true even if there
is just one server!  You can't solve this problem by better cataloguing
technology.




> Well, it is kinda funny. You don't want UUIDs, and Craig always tells me
> that they are crucial.
> IMHO I want them but I give you the choice if you want to use them or
> not.

Obviously they are not *crucial* since Debian is doing extremely well
without them.

And it is not my choice, by the way.  If people use UUID's and start
renaming their packages all the time, I will be forced to use UUID's as
long as I collaborate with all you heretics.  :)


> If I write a load script (and yes, that will eventually be phased out
> when we get proper dependencies) I would want it to work regardless if
> the package is renamed in the future. Thus *I* would use a UUID. But I
> think almost all of those methods also have a name based variant.

Granted.  However, I don't think renaming is worth it if I have to use
UUID's all the time.  Aside from that, I like being able to talk about
modules to peolpe, and I thoroughly intend to keep saying "you can
download Chuck" instead of "you can download <gobblygook>".  There are a
lot of situations where you can hide the UUID, for example GUI tools and
web sites.  In other places it is utterly unavoidable, however: email,
talking, and printed text.  In the latter circumstances one must choose
between using the name or the UUID, and one loses something no matter
which way they choose.  In practice, I bet people use names all the
time.  Names are nice.

But anyway, it's a minor issue compared to the others.


-Lex