Daniel Vainsencher wrote:
> 
> Lots of this-is-how-it-should-be-bla-bla. New(?) proposed requirements for
> ProL below ***s.

???

> 
> First of all, I think the the Project Layers work is very interesting.
> I love two consequences of it -
> 1. Anyone can create demos/explanations/tutorials and distribute them in a
> form that's really accessible to end users (which fileins are not...).
> 2. Anyone can create generic packages in such a form.
> 
> To me the first is important because of the large potential number of added
> creators/markets of content.
> The second is important because of the great number of different applications
> for it. These include a modification of the "Squeak Universe" in which we
> operate.
> 
> I think there's a lots of noise happening to the effect that people want
> easier access to other people code, without waiting for it to hit the top of
> SCs priority queue.
> 

I agree.

But there are different kind of peoples who want to get code from other
peoples:
- end users, who just want to use nice applications,
- application developers, who want to use good packages of code to write
these nice applications,
- package developers, who write these packages which could and should be
used by others,
- core developers (just don't find a better description), who want to
improve and extent the Squeak VM directly or by plug-ins.

It's very important to find good solutions for these very different
demands of which code to get and to work with.
E.g. an end user doesn't want to search for different packages and be
shocked by incompatibilities of different packages.

I think it's important to minimize maintenance problems:
Think of the problems of installing apps at WinNT with different
drivers, service packs, incompatible file formats, etc..
It would be very appealing if this could be avoided for Squeak. And now
it is in a quiet early state where very important decisions have to be
made which strongly influence the future of Squeak.

BTW: See also my post called 'Structuring packages to minimize 'bad'
dependencies' for more principle thoughts.

> There are several projects happening in the squeak world that would benefit
> from having the sort of distribution prowess that SC enjoys. (Stephan's
> images, MathMorphs, Craig's correspondents?, the raw bug-fix stream (if you're
> adventurous)...).
> 
> I propose the image hold a (growable) list of sites (SC, minnow, Fred's Squeak
> Warez...). Each site will hold a list of update streams and the contents for
> each. Some of the sites may allow posting of fixes by anyone (restricted
> versions might also be useful).
> 
> A simple application will allow the user to see how many and what updates are
> available for each stream he has registered.
> 
> Note that the update numbering is per list. From a short look at the code for
> updates, not much separates the update streams from being multiple, but the
> numbering is one of those things.

Could be the way of choice, if there is a good separation between these
different applications/packages/VM-extensions and not to much
interdependencies between these codes from different sources.

> 
> ***
> Some needs I wish to raise -
> 1. (Not to the point) I want to have an arbitrary number of update stream
> coming into my Squeak. (but suggests - )

Remark: end user want to have fun with apps, not to update at all...

> 2. I can monitor/control which projects each stream may modify. (I want to
> accept all modifications from SC, all modifications from the MorphicWrappers
> stream, but only to the MW project, so forth).
> 3. I want to have a Preferences project which is generally not updated (maybe
> only added to) by any streams. Sick of reconfiguring things.
> 4. Same should go for Celeste. This means the image should be able to find
> local, persistent repositories and connect to them easily.

All is interesting and good for developers and some say 'power user'.
(BTW: what's Celeste?)

> 5. When the project you're in chokes, allow a key press to send you to another
> project, with a debugger tuned to the world you left, so that the debugger
> works in it own plain vanilla project, but simulates life in another. This is
> another line of defense against screwing up a more-basic-than-you-thought
> method.
 
Don't understand this point: A debugger in environment A should
continuing work in environment B? Why?

> BTW, it seems that distributing images will become even less important (update
> streams have made that needed mostly for PWMs). Download a minimal image +
> sources (that can be *very* stable) and you're mostly set. This leaves only
> the VM both platform specific and volatile. And with plugin primitives, we
> might cool the VM down too. Thats pretty cool.

I agree, that would be pretty cool!

> 
> Daniel

Regards,

Stephan Rudlof