Hi Paul.

That's not exactly my point - I don't think there's a technical problem
here with ModSqueak.

we need to face these questions:

* Do people *want* to work in modules all the time? They aren't now.
(SqC, for example)
* How do we handle mixed situations (either the transition period, or a
stable state)?

I'm saying this because it seems we might enter this transition time any
time now, I think we should have an idea on how.

PS, Paul, if this is veering outside the modsqueak at bluefish.se
appropriate usage, don't include it in the reply. I guess you know the
house rules better than I...

> > * and not see all the new cool eToy stuff SqC is
> > working on?
> > * and anyway, if Lex and Daniel do start maintaining
> > Celeste in a module
> > outside the SqC image, how does this mix in with the
> > updates review
> > team? 
> > * how will I get the bug fixes and tweaks for
> > Celeste, if that's not in
> > the update stream?
> -- I think the end goal (one of them) should be for
> ModSqueak to provide its facilities in a robust
> enough, and distributed enough, fashion for both SqC
> and the rest of us to work in modules.  As long as at
> some point along the chain the source code can be
> converted to a standard such as SIF, or (later?)
> another accepted standard, ModSqueak shouldn't really
> care where it came from.  Changesets can easily be
> translated into Packages, for example, so it's not
> hard to imagine enabling a ModSqueak "server" to talk
> to client images in changeset format.  Having that
> work robustly ... is a tad more difficult to image.
> 
> Just thinkin' out loud really,
> Paul
> 
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
> http://im.yahoo.com