About Configurations
Locked
12
12
 
|
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. |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 > |
|
|
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 >> > > |
|
|
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 >>> >> >> > > |
|
|
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 |
|
|
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 |
|
|
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
|
|
|
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 |
|
|
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 |
|
|
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 > > > |
|
|
> 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 >> >> >> > > |
|
|
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 >>> >>> >>> >> >> > > > |
|
|
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 |
|
|
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 > |
|
|
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
|
|
|
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 > > > > |
|
|
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
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |