[squeak-dev] SqueakMap is a "Showroom"

Damien Pollet damien.pollet at gmail.com
Sat Jun 28 19:39:02 UTC 2008


On Sat, Jun 28, 2008 at 7:25 PM, Chris Muller <asqueaker at gmail.com> wrote:
>>> ...
>>> Once you've got them together you can easily post your own *new* MPSS
>>> to SqueakMap which combines the function of the other two.
>>
>> So basically, either users duplicate the integration work for
>> combinations of packages not prepared before, ...
>
> If a combination wasn't prepared and published before then, by
> definition, that combination hasn't been meaningful enough as a
> singularity for anyone to have performed such integration.  Since it
> hasn't been done before, there's no duplication of work.

Maybe. But ideally a package manager doesnt even require the work to
be done. Each package *locally* defines what it needs and what it
provides, and "integrating" is just choosing something else than the
default when there are several possibilities to fulfill a dependancy,
effectively making a new adhoc composition.

> You forgot to do step 1.  Reduce your expectation of SqueakMap from
> being a "packaging system".  That's Monticello.  Instead, SqueakMap is
> just a showroom from which you expect to be able to *easily* review
> and learn about a package.  This is why I encourage SqueakMap packages
> to not be shy about pop-ups to introduce the package to the user, even
> utilising Squeaks multimedia capabilities in an engaging way if
> possible.  Talk about on-line documentation and the attraction that
> would be for new users (and me too!).

Then this is useful only once per user, at the first installation.
IMHO this would be better fulfilled by having nice (read HTML with
links and images) class/package comments in the image and a way to
navigate them like a manual rather than randomly picking classes and
methods. SqueakMap should also present these comments online so you
can see what the package does before installing it.

However, this is orthogonal to the need to say "I need X" and have the
system automatically install all the necessary, while not forcing
people to maintain each and every used combination separately.

Ex. Pier needs Seaside. If there is a new release of Pier, the Pier
developers update the Pier package and nothing more. If Seaside gets
upgraded, the Pier package should *not* have to change/be
regenerated/whatever until the Pier code is updated.

> I really like what OSProcess does when it loads up, showing you the
> current VM process and some docuementation.

Do you like to close the same 12 windows each time you rebuild an
image or upgrade the package ?
What when OSProcess gets installed because it is used behind the
scenes by the actual thing you want ?

-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet



More information about the Squeak-dev mailing list