Dear all

I am glad that the topic of Configurations is in focus again this month.

In May 2010 this year we had done a prototype based on Metacello
configurations. Andreas had provided two GUIs (a hierarchical one and
a "flat" one)  which collected the meta data from ConfigurationOfXYZ
classes (e.g  ConfigurationOfSQLite3
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150816.html
)

See more in the thread started by
Dale Henrichs - Community Supported Packages
(takeing on the proposal by Andreas Raab)
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150673.html

What is different now as of July 2010 that Andreas proposes the GUI
not to base the lists of things to load directly on MetaCello
configurations but to include a level of indirection.

Instead of basing the GUI on MetaCello configuration classes it should
be based on "catalogue entries" (or generally meta information). An
entry may still include the info that a MetaCello configuration class
has to be loaded but other means of getting things into the image
would be allowed as well.

This is of course related to SqueakMap and Universes as other people
have pointed out in this thread.

I think some of the differences are

1) we are talking about a subset of "Community Supported Packages"
which have to be tested with the image (if possible automatically).
Realistically speaking at this moment probably about 30 packages.
(Universes was much more, SqueakMap is many hundreds).
Examples are WebClient, SQLite, Magma, XML parser, Regex, JSON, Email
client, some Games, Seaside, OmniBrowser,...   and more)

2) the catalog info for loading things should reside _in_ the image
(contrariwise to SqueakMap and Universes).

3) The emphasis is on providing a nice GUI so that people can load
things easily into a Squeak 4.2 image.

4) The system should encourage and facilitate "Community
participation". Goran's time is limited and Lex has moved on to
another environment. Dependency on key people to have time should be
minimized.

5) The Configurations systems actually is something like a "plugin
system". It allows to grow the developer base for Squeak without
running into problems of needing to negotiate things on a very
detailed level.

Did I capture the intent with these five points?

To summarize: I think the new aspect of a level of indirection in
between the GUI and the code which actually loads additional code is
useful.

Regards

Hannes


On 7/14/10, David T. Lewis <lewis at mail.msen.com> wrote:
> On Tue, Jul 13, 2010 at 06:41:13PM -0700, Andreas Raab wrote:
>> On 7/13/2010 6:09 PM, Colin Putney wrote:
>> >Well, in that case, we're effectively talking about SqueakMap, right?
>> >Maybe implemented differently, but basically a catalog of things you can
>> >install, with some metadata about how to actually perform the install,
>> >using a method appropriate to the package.
>>
>> Well, I don't *think* of it as SqueakMap but the comparison is somewhat
>> appropriate. The main reason why I don't think of it as SM is that SM
>> wants to be "all packages ever created for Squeak" but what we need is
>> "all packages that we've actually tested to work in this image". And of
>> course there are some other differences (like community ownership
>> instead of individual ownership of the catalog elements) but other than
>> that I agree; it would probably be quite similar to SM in what it does.
>
> I think that perhaps a closer analogy is Lex's Universes:
>
>   http://wiki.squeak.org/squeak/3786
>   http://wiki.squeak.org/squeak/3785
>
> That concept has been poorly applied (which may in itself indicate a flaw
> in the concept, though I prefer to view it as lack of the necessary
> benevolent dictatorship). But the ideas behind it were and still are
> quite valid.
>
> Of course Goran has previously discussed merging SM and Universes, which
> would have been great if somebody had actually done it. The basic idea is
> that SqueakMap is "all packages ever created for Squeak" and a Universe
> is "all packages that we've actually tested to work in this image". The
> two together are a package management system.
>
> Hopefully we can now move those concepts forward. Metacello seems to
> offer a way to provide a map to all known packages as well as a clear
> definition of how to load the right version of each into a given image.
> If we can add a thin layer to describe the subset of the Metacello
> map that constitutes the universe of things that work in this image,
> then we have more or less exactly what Goran and Lex intended, with
> the additional benefit that it all works nicely with Monticello.
>
> Dave
>
>
>