(This is a response to a message Avi sent just to me, but meant to send
to the list as well [really-- I asked :] )

Hi Avi--

> So you envision the minimal snapshot as a purely deployment
> environment at first, with development hosted elsewhere?

        Until we have the modules needed to turn the minimal snapshot
into a
comfortable development system, yes.

> Are you picturing that the code under development would live in the
> minimal snapshot, but that you would connect to it from a full image
> that contained a UI and dev tools, sort of like GemStone and
> GemBuilder?

        No; although I do have that capability now, I've only needed it
so far
for ripping things out and putting the module-installation behavior in,
and I don't see that changing out of necessity. I can imagine other uses
for remote browsing, though.

> Or just that you would develop the code under a full image, package
> it into a module, and then load it into the minimal snapshot for
> deployment?

        That's basically right, although the distribution mechanism is
nice in
what I think are novel ways (as described in the 13 November 2003
progress
report). As I mentioned above, though, I intend for each author's
development snapshot to be composed from the minimal one and available
modules. Whether "at first" includes that bootstrapping period is for
each person to decide (whether they want to be involved :).

> If the latter, then then snapshot can't be radically different from
> the full image - if Squat uses Flow, then Flow needs to also be
> available in Squeak so we can develop with it.

        Well, right now, the development snapshot I'm using is just a
recent
parent of the minimal one, and not that much different than Squeak 2.2.
Flow is available there; adapting it to be there was the first thing I
did. Since every snapshot made from it will have Flow available, that
problem goes away. (Note that one can still unload Flow if they want.) 
I'm not against supporting interaction between series 3 snapshots and
Squat snapshots, but I don't think I'll have time to help with that for
a while.

        I hope that the SqueakMap effort (carving the snapshot up into
areas of
responsibility, taking things out and putting them into packages) will
get people used to the idea of snapshots with less stuff in them. It may
even be that after some amount of the current reduction process, we can
just make a swap. I would still think of SqueakMap support as "backward
compability" though, since I'd personally rather move toward live
interaction through message-sending, and away from files as a
distribution mechanism.

> The cognitive dissonance of developing in an environment with similar
> but incompatible classes to those I'm developing *with* would be
> frustrating - why would I want to keep two stream frameworks in my
> head?

        Oh, of course; I would never put up with that normally, and I
wouldn't
ask anyone else to either.

> I would be surprised if any serious planning... happened
> before a demo was released...

        Hmm, then it's a good thing I'm working on it, otherwise it
would
*never* get discussed? :)  That surprises me. I think it'd be fine to
discuss this stuff before there's anything working, so that we can have
a better idea of our goals and desires. In the past, the discussion has
often come after the wrong thing got built, and it's a shame.

> > > ...or how much work is it for any one of them to make it into a
> > > module?
> >
> >       How much work should it be? Now we're having the discussion. :)
> 
> :) As little as possible, of course.

        Ah, so the only acceptable answer so far appears to be "no work
at all;
it's already done!". :)

> I think the single most important thing is to prevent forking. I am
> not going to maintain a package for two "dialects" of Squeak (eg, one
> with Flow and one without).

        Sure, but there will inevitably be multiple packages that
fulfill the
same roles, and some authors will make different choices about which
ones they want as their prerequisites. I think it's a surmountable
issue. I certainly intend to keep Flow a good citizen: it will go away
after initial system startup if that's what a user wants, and it won't
keep some other networking infrastucture package from working if the
user lets it stay around.

> Ideally, Squat would be a strict subset of the full image.

        Ideally, the full image would be a strict superset of Squat. :) 
And my
development image right now is just that, although it is considerably
smaller than what someone used to 3.7 would expect. Hopefully a few
other weirdos will help get first few modules in there (even if they
aren't the original authors); I think that'll take about six months.
Then most authors would probably be keen to jump in.

        Or it could just be me, that's fine. :)

> > > From your reports, you've done an amazing job stripping down the
> > > image, but surely it's an even bigger task to be able to build
> > > it back up again?
> >
> > Yes, but it's also much easier to distribute that task over many
> > people, so I think on balance it's a win. I certainly think it's
> > worth doing.
> 
> Absolutely. I think it's essential, and I also think it's going to
> take several years. Those aren't incompatible points of view.

        I didn't say they were, I was just pointing out some additional
information that I thought was worth mentioning. :)  (I do suspect the
time would be somewhat shorter though, like a couple of years.)


        thanks again,

-C

--
Craig Latta
http://netjam.org/resume
craig at netjam.org
[|] Proceed for Truth!