Thank you Andreas for the feedback.

Something which came to my mind this morning.

The additional requirement raised in this thread is that the
installation GUI should be able to load non-MetaCello files.

But this does _not_ necessarily mean everything has to be indirected.

So installation GUI still can show the MetaCello ConfigurationOfXYZ
classes which are around as the May prototypes do. The new thing is to
add (maybe with constant methods in the GUI giving literal arrays)
some non-MetaCello things.

So I would plead for the inclusion of the installation GUI as of May
2010 with some extension mechanism to accomodate non-MetaCello
extension.

What do you think?

--Hannes

On 7/14/10, Andreas Raab <andreas.raab at gmx.de> wrote:
>  > Did I capture the intent with these five points?
>
> Yup. Great summary, thanks!
>
> Cheers,
>    - Andreas
>
> On 7/14/2010 8:48 AM, Hannes Hirzel wrote:
>> 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
>>>
>>>
>>>
>>
>>
>
>
>