goran.krampe at bluefish.se
goran.krampe at bluefish.se
Thu Mar 10 12:55:48 UTC 2005
Avi Bryant <avi.bryant at gmail.com> wrote:
> On Wed, 9 Mar 2005 15:51:26 +0100, goran.krampe at bluefish.se
> <goran.krampe at bluefish.se> wrote:
> > I do have an idea that we could add "Universe" as a new "type" of thing
> > on SM, just as I would like to add "image" as another type, and possibly
> > even "repository" (Monticello).
> That's a very interesting thought; as I understand it, the goal of
> SqueakMap was always to "map" the Squeak community in general, rather
> than to be a list of packages. I think this is a great goal, and one
> we should try to keep sight of. The question is, what are the most
> interesting things to map? At first, packages were an obvious choice,
> but I think Lex makes a very compelling argument that as we move
> forward we should be thinking in terms of sets of package versions
> rather than in terms of individual packages. In light of that, what
I agree that "sets of package versions" or Universes is a nice concept.
I still believe that it isn't the *only* way of managing dependencies -
but it sure is *one* way of doing it.
> if we migrated SqueakMap towards keeping a list of package Universes
> rather than a list of packages? It would remain in its familiar and
> extremely useful status as the gateway to the Squeak world, but would
> delegate the responsibility for package-level granularity to the
> individual Universes.
Eh, hmm. That would indeed make Universes the *only* way of managing for
example dependencies, and I do have another way in mind. What I instead
was thinking was this:
In the next SM I am introducing SMResource which is an unversioned
"thing" on SM (compared to SMPackage which keeps track of its releases).
So an SMResource will also have a URL and various other attributes like
name, description etc, but only keep track of the "current" version
using typically a version field (much like SM1 did).
A Universe could then be such an SMResource. And if you install a
Universe it simply means downloading/installing the current version of
it. Since a Universe basically is a list of references to
SMPackageReleases (or could be at least) and their direct deps I don't
think it would be practical nor suitable to keep track of every
"release" of the Universe itself (=every time it is changed) - thus the
idea to model it as an SMResource.
I haven't had time to look at Lex's Universe code yet - so I don't know
if he uses SM to get to the actual releases, but anyway, the above
scheme doesn't really care what a Universe *is* - it will just be
something that SM can download (a URL) and then fire up an installer on.
An SMResource could use an SHA to be able to know if it has indeed
changed since it was last downloaded - or it can be triggered by the
version "field" having changed.
I am still unsure if Lex is interested in merging Universes with SM or
as I describe above we simply make SM able to map them and get to them.
If Lex wants to continue with Universes totally separate from SM
(meaning no merging) then I will simply make sure SM handles them as I
always want SM to handle stuff in the Squeak community - it would then
seem very stupid to add a similar mechanism to SM because then we would
have two such competing mechanisms.
More information about the Packages