About Configurations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

About Configurations

Casey Ransberger-2
I thought this was a bang-up idea. Any particular reason the Configurations package hasn't made it into the Trunk? Anything I can do to help? 

--
Casey Ransberger, who should be writing documentation right now.


Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Andreas.Raab
On 7/12/2010 10:17 PM, Casey Ransberger wrote:
> I thought this was a bang-up idea. Any particular reason the
> Configurations package hasn't made it into the Trunk? Anything I can do
> to help?

Mostly because I've been second-guessing myself. After playing with it
for a while it felt like bad fit for the job. Perhaps others have an
insight on this, but my feeling of what this is supposed to be doing is
to provide an easy and straightforward way to install "new stuff". As
such, I would expect it to look more like a Windows (or Mac) installer
that is listing features for example:

        WebClient Options:
                [x] Code (required)
                [x] Tests (optional)
                [x] Documentation (optional)

instead of something like apt or rpm (i.e., even in the Ubuntu Software
Center it's virtually impossible to figure out what the name of the
package with the necessary headers for X11 is). Unfortunately, Metacello
resembles more the latter than the former and I'm not sure it's a good
idea to try to transform from one into the other.

In addition, Metacello's heavyweight nature keeps bothering me. It may
be fine to load Metacello for something complex like Seaside, but *lots*
of good things (say the games) are single MCZ package installs where the
overhead of installing Metacello completely dominates everything else.
And given that in such a case Metacello does nothing that Installer
can't do in a single line it leaves me wondering why we'd use such a
high-overhead solution.

So I've been thinking if it isn't better to regroup things and define
that the stuff that comes with the image is more light-weight than
Metacello by default - it may *use* Metacello for installing it where
that's desirable but it wouldn't require Metacello for simple things.
Instead, it would focus more on those "installer options" that say from
a user perspective here are the things that you may want to install and
they boil down into some packages.

Basically, it would boil down to a "configuration" (needs a different
name to avoid confusion) being a container of information about a piece
of software. It contains the authore, description, and other meta info,
has a set of installable options, and knows what further code to run
when any such option is selected. So that, for example, in Seaside your
options might be something along the lines of:

        Seaside 3.0 options:
                [x] Seaside (required)
                [x] Pier (optional)
                [x] Extras (optional)

which then map into installing particular targets from the associated
Metacello configuration.

The other advantage of this approach would be that it can introduce a
form of "late-binding" in the installation process. For people who want
to maintain their package(s) elsewhere (Seaside or OB) it introduces an
indirection where the "in-image" configuration simply defers to the
"ex-image" configuration. We had talked about this in the past and this
would make that pattern explicit.

And of course, for the simple packages we'd literally just use the
one-line Installer loading mechanism.

Comments welcome.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

David T. Lewis
On Mon, Jul 12, 2010 at 11:24:27PM -0700, Andreas Raab wrote:
> On 7/12/2010 10:17 PM, Casey Ransberger wrote:
> >I thought this was a bang-up idea. Any particular reason the
> >Configurations package hasn't made it into the Trunk? Anything I can do
> >to help?

<snip>

> So I've been thinking if it isn't better to regroup things and define
> that the stuff that comes with the image is more light-weight than
> Metacello by default - it may *use* Metacello for installing it where
> that's desirable but it wouldn't require Metacello for simple things.
> Instead, it would focus more on those "installer options" that say from
> a user perspective here are the things that you may want to install and
> they boil down into some packages.

+1

I like the idea of *encouraging* use of Metacello, but not requiring it
for simple things. The ConfigurationOfWhatever classes are lightweight
and they do document the targets of the configuration nicely, but they
still require loading a good deal of infrastructure before a package can
be loaded.  So I think it is good for the stuff that comes with the image
to be as thin as possible.

As an example fresh from today's postings, consider German Arduino's
SimpleLogger package on SqueakSource. It is admirably small, it seems
useful, and it would work fine on any Squeak/Pharo variant. The
ConfigurationOfSimpleLogger might well be larger than the package
itself. It would be good to permit loading things like this through
the simplest (and fastest) available mechanism.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Andreas.Raab
On 7/13/2010 4:57 PM, David T. Lewis wrote:

> I like the idea of *encouraging* use of Metacello, but not requiring it
> for simple things. The ConfigurationOfWhatever classes are lightweight
> and they do document the targets of the configuration nicely, but they
> still require loading a good deal of infrastructure before a package can
> be loaded.  So I think it is good for the stuff that comes with the image
> to be as thin as possible.
>
> As an example fresh from today's postings, consider German Arduino's
> SimpleLogger package on SqueakSource. It is admirably small, it seems
> useful, and it would work fine on any Squeak/Pharo variant. The
> ConfigurationOfSimpleLogger might well be larger than the package
> itself. It would be good to permit loading things like this through
> the simplest (and fastest) available mechanism.

Yes, that is exactly the kind of package I had in mind.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Casey Ransberger-2
So I guess what I'm wondering is, does what we have support this approach with a bit of extra work, or do we need to scrap it and implement something else, which knows to load (for example) Metacello when loading up Seaside? I doubt we really want to load Seaside differently than the Seaside developers do... Right?

On Jul 13, 2010, at 5:31 PM, Andreas Raab <[hidden email]> wrote:

> On 7/13/2010 4:57 PM, David T. Lewis wrote:
>> I like the idea of *encouraging* use of Metacello, but not requiring it
>> for simple things. The ConfigurationOfWhatever classes are lightweight
>> and they do document the targets of the configuration nicely, but they
>> still require loading a good deal of infrastructure before a package can
>> be loaded.  So I think it is good for the stuff that comes with the image
>> to be as thin as possible.
>>
>> As an example fresh from today's postings, consider German Arduino's
>> SimpleLogger package on SqueakSource. It is admirably small, it seems
>> useful, and it would work fine on any Squeak/Pharo variant. The
>> ConfigurationOfSimpleLogger might well be larger than the package
>> itself. It would be good to permit loading things like this through
>> the simplest (and fastest) available mechanism.
>
> Yes, that is exactly the kind of package I had in mind.
>
> Cheers,
>  - Andreas
>

Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Andreas.Raab
On 7/13/2010 5:35 PM, Casey Ransberger wrote:
> So I guess what I'm wondering is, does what we have support this approach with a bit of extra work, or do we need to scrap it and implement something else, which knows to load (for example) Metacello when loading up Seaside? I doubt we really want to load Seaside differently than the Seaside developers do... Right?

Right. The "current approach" (which is really more like "the initial
proposal") was to include the Metacello configurations verbatim in the
configuration package. What I'm proposing as a refinement is an
indirection before that - instead of a Metacello configuration in the
image you have "something else" which provides enough information to
display and install the desired features.

What exactly the "something else" might be is open for debate but I
think I'd like to drive it from the UI side, i.e., what do you want to
see and specify when you install a piece of software? (think app store)

This approach doesn't invalidate the work that has been done; it puts a
(hopefully) prettier face in front of it to make it easier and more
obvious what you're about to get.

Cheers,
   - Andreas

> On Jul 13, 2010, at 5:31 PM, Andreas Raab<[hidden email]>  wrote:
>
>> On 7/13/2010 4:57 PM, David T. Lewis wrote:
>>> I like the idea of *encouraging* use of Metacello, but not requiring it
>>> for simple things. The ConfigurationOfWhatever classes are lightweight
>>> and they do document the targets of the configuration nicely, but they
>>> still require loading a good deal of infrastructure before a package can
>>> be loaded.  So I think it is good for the stuff that comes with the image
>>> to be as thin as possible.
>>>
>>> As an example fresh from today's postings, consider German Arduino's
>>> SimpleLogger package on SqueakSource. It is admirably small, it seems
>>> useful, and it would work fine on any Squeak/Pharo variant. The
>>> ConfigurationOfSimpleLogger might well be larger than the package
>>> itself. It would be good to permit loading things like this through
>>> the simplest (and fastest) available mechanism.
>>
>> Yes, that is exactly the kind of package I had in mind.
>>
>> Cheers,
>>   - Andreas
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Casey Ransberger-2
Okay, got it. Sounds cool; I hope it might also be easy to install w/o UI (i.e. from a script) whatever it winds up being.

Are you volunteering, Andreas? :)

One nice thing about putting a facade in front of those tools might be that we could discard them much more easily if something better came along some day without necessarily having to redo all of our package definitions...

On Jul 13, 2010, at 5:41 PM, Andreas Raab <[hidden email]> wrote:

> On 7/13/2010 5:35 PM, Casey Ransberger wrote:
>> So I guess what I'm wondering is, does what we have support this approach with a bit of extra work, or do we need to scrap it and implement something else, which knows to load (for example) Metacello when loading up Seaside? I doubt we really want to load Seaside differently than the Seaside developers do... Right?
>
> Right. The "current approach" (which is really more like "the initial proposal") was to include the Metacello configurations verbatim in the configuration package. What I'm proposing as a refinement is an indirection before that - instead of a Metacello configuration in the image you have "something else" which provides enough information to display and install the desired features.
>
> What exactly the "something else" might be is open for debate but I think I'd like to drive it from the UI side, i.e., what do you want to see and specify when you install a piece of software? (think app store)
>
> This approach doesn't invalidate the work that has been done; it puts a (hopefully) prettier face in front of it to make it easier and more obvious what you're about to get.
>
> Cheers,
>  - Andreas
>
>> On Jul 13, 2010, at 5:31 PM, Andreas Raab<[hidden email]>  wrote:
>>
>>> On 7/13/2010 4:57 PM, David T. Lewis wrote:
>>>> I like the idea of *encouraging* use of Metacello, but not requiring it
>>>> for simple things. The ConfigurationOfWhatever classes are lightweight
>>>> and they do document the targets of the configuration nicely, but they
>>>> still require loading a good deal of infrastructure before a package can
>>>> be loaded.  So I think it is good for the stuff that comes with the image
>>>> to be as thin as possible.
>>>>
>>>> As an example fresh from today's postings, consider German Arduino's
>>>> SimpleLogger package on SqueakSource. It is admirably small, it seems
>>>> useful, and it would work fine on any Squeak/Pharo variant. The
>>>> ConfigurationOfSimpleLogger might well be larger than the package
>>>> itself. It would be good to permit loading things like this through
>>>> the simplest (and fastest) available mechanism.
>>>
>>> Yes, that is exactly the kind of package I had in mind.
>>>
>>> Cheers,
>>>  - Andreas
>>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Colin Putney
In reply to this post by Andreas.Raab

On 2010-07-13, at 5:41 PM, Andreas Raab wrote:

> On 7/13/2010 5:35 PM, Casey Ransberger wrote:
>> So I guess what I'm wondering is, does what we have support this approach with a bit of extra work, or do we need to scrap it and implement something else, which knows to load (for example) Metacello when loading up Seaside? I doubt we really want to load Seaside differently than the Seaside developers do... Right?
>
> Right. The "current approach" (which is really more like "the initial proposal") was to include the Metacello configurations verbatim in the configuration package. What I'm proposing as a refinement is an indirection before that - instead of a Metacello configuration in the image you have "something else" which provides enough information to display and install the desired features.
>
> What exactly the "something else" might be is open for debate but I think I'd like to drive it from the UI side, i.e., what do you want to see and specify when you install a piece of software? (think app store)
>
> This approach doesn't invalidate the work that has been done; it puts a (hopefully) prettier face in front of it to make it easier and more obvious what you're about to get.

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.

Colin
Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Casey Ransberger-2
Yeah, but I think we want what versions of things are installed to be checked into the trunk so that they're guaranteed to work with the release the image is based on. With SM we don't get that.  

On Jul 13, 2010, at 6:09 PM, Colin Putney <[hidden email]> wrote:

>
> On 2010-07-13, at 5:41 PM, Andreas Raab wrote:
>
>> On 7/13/2010 5:35 PM, Casey Ransberger wrote:
>>> So I guess what I'm wondering is, does what we have support this approach with a bit of extra work, or do we need to scrap it and implement something else, which knows to load (for example) Metacello when loading up Seaside? I doubt we really want to load Seaside differently than the Seaside developers do... Right?
>>
>> Right. The "current approach" (which is really more like "the initial proposal") was to include the Metacello configurations verbatim in the configuration package. What I'm proposing as a refinement is an indirection before that - instead of a Metacello configuration in the image you have "something else" which provides enough information to display and install the desired features.
>>
>> What exactly the "something else" might be is open for debate but I think I'd like to drive it from the UI side, i.e., what do you want to see and specify when you install a piece of software? (think app store)
>>
>> This approach doesn't invalidate the work that has been done; it puts a (hopefully) prettier face in front of it to make it easier and more obvious what you're about to get.
>
> 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.
>
> Colin

Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Chris Cunnington
In reply to this post by Casey Ransberger-2
CP said: "Well, in that case, we're effectively talking about SqueakMap, right?"

Göran has had a rewrite of SqueakMap brewing in his mind for a long time. It would be worthwhile, if he could outline what those ideas are here on the board. 

It's possible that the existing SqueakMap could evolve into what we need. But the UI for SM right now... I think that has several deficiencies. A better UI would be a priority.

Chris


Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Andreas.Raab
In reply to this post by Colin Putney
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.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Hannes Hirzel
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 <[hidden email]> 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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Andreas.Raab
 > 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<[hidden email]>  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
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Hannes Hirzel
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 <[hidden email]> 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<[hidden email]>  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
>>>
>>>
>>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Chris Cunnington
In reply to this post by Casey Ransberger-2

I think our debate about configurations may be drifting out of the right scope. We have lots of ways of adding small programs. We don't have a way to make Morphic an option. We need a GUI widget that presents itself on a 5 meg image. Then people choose an appropriate build.


Chris 



Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Hannes Hirzel
Chris, does this imply that you are fine with a MetaCello
configurations based GUI as we had in May?

--Hannes

On 7/15/10, Chris Cunnington <[hidden email]> wrote:
> I think our debate about configurations may be drifting out of the right
> scope. We have lots of ways of adding small programs. We don't have a way to
> make Morphic an option. We need a GUI widget that presents itself on a 5 meg
> image. Then people choose an appropriate build.
>
>
> Chris
>

Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Chris Cunnington
In reply to this post by Casey Ransberger-2
Yes. I'm for the GUI mockup I created (based on TestRunner) and not for the gui mockup Andreas created (based on SqueakMap). The details are in those posts. I'm just not sure what problem we're trying to solve. I think it'd be exciting to use configurations to shrink the image to 5 megs. But I'm not the community, so the more opinions we get from people, the better. 

Chris 


Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Andreas.Raab
On 7/16/2010 9:02 AM, Chris Cunnington wrote:
> Yes. I'm for the GUI mockup I created (based on TestRunner) and not for
> the gui mockup Andreas created (based on SqueakMap). The details are in
> those posts. I'm just not sure what problem we're trying to solve.

Generally speaking the problem of having an easy, straightforward and
robust way to install (and then test, and perhaps uninstall) community
supported packages.

Cheers,
   - Andreas

> I think it'd be exciting to use configurations to shrink the image to 5
> megs. But I'm not the community, so the more opinions we get from
> people, the better.
>
> Chris
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: About Configurations

Chris Cunnington
In reply to this post by Casey Ransberger-2
It's impossible to disagree with what you've just said, but what's a package? My question is at what point does something become so large that it's not a package? At what point is something so large that it cannot be left out? I'd like to see Morphic and MVC be packages. I'd like to see Collections, Graphics, Network, and Compiler become packages. 

Chris 


12