On 7/9/09 9:38 AM, "Colin Putney" <cputney at wiresong.ca> wrote:

> Hi Milan,
> 
> Thanks for taking the time to reply. Those do seem to be the available
> options, but I think I'd order them with #1 and #2 reversed. I think
> what we have now is the least desirable state of affairs. Further
> comment inline:
> 
> On 5-Jul-09, at 11:53 PM, Milan Zimmermann wrote:
> 
>> Colin,
>> 
>> Thanks for taking a fresh look at this. My Etoys/Squeak
>> synchronization
>> approaches are, from the "least desirable" to the "most desirable":
>> 
>> #1. Remove Etoys from Squeak, as some suggested:
>> - Cons and Questions: Where is the boundary between Morphic and
>> Etoys? Does
>> it mean Morphic removal as well? What does it mean for Squeak in
>> education?
>> - Pros: None for me. I voted for board individuals who I assumed
>> would not
>> support this.
> 
> I think this implies that the Squeakland distribution remains separate
> from Squeak, and gradually diverges, as Squeak becomes less and less
> Etoys-compatible. It also means, I think, removing Etoys but not
> Morphic. The boundary can be somewhat arbitrary, and the freedom to
> break Etoys compatibility makes it easier to clean up Morphic over time.
> 
>> #2. Do nothing
> 
> Does this really mean nothing at all, or are you imagining that Squeak
> gets updated to the latest Etoys, even though we can't draw a line
> around it and manage it with Monticello? If you mean nothing at all,
> I'd say this is the least desirable scenario. If nobody is using the
> Etoys code in Squeak, it should be removed. On the other hand, if we
> can get Squeakland using a vanilla Squeak 3.11 (or whatever the
> release is called) it would be worth living with the kernel bloat for
> a while longer.
> 
>> #3. Achieve ability to Manage Etoys+Morphic as single Monticello
>> project.
>> Unload existing Morphic+Etoys version from Squeak, and replace it
>> with the one
>> in Etoys 4.0 image
>> - Cons: Boundary between Morphic and Etoys remains undefined. Would
>> be nice,
>> but it may be impossible given the time we have.
>> - Pros: Refresh of Etoys (and some Morphic elements) from the work
>> made for
>> OLPC in the last 2 years. This was a significant investment!
> 
> It seems like this could be done in the reverse as well - update
> Morphic/Etoys from the Etoys 4.0 image, then draw the line around it
> and make it a Monticello package.
> 
>> #4. Define Boundariies between Morphic and Etoys. Achieve ability to
>> Manage
>> Morphic as one Monticello project and Etoys as a separate Monticello
>> project.
>> Unload existing Morphic+Etoys version from Squeak, and replace at
>> least  Etoys
>> from the Etoys 4.0 image
>> - Cons: None for me. Except we may not have enough time to achieve
>> this...
>> - Pros: Refresh of Etoys (and some Morphic elements) from the work
>> made for
>> OLPC in the last 2 years. This was a significant investment! Ability
>> to manage
>> Morphic and Etoys separately would unlock much potential (e.g.
>> replace Morphic
>> with Morphic2 and keep Etoys functional on top of Morphic2)
> 
> Sure. This is definitely the ideal.
> 
> It occurs to me that your numbering could represent steps in a
> progression rather than a prioritizing mutually-exclusive
> possibilities. #1 has already been done, a few different ways.
> Understanding what gets removed when we create an image without Etoys
> is a good first step. Even more important are the changes that have to
> be made to the base image to keep it running correctly in the absence
> of Etoys.
> 
> #2 might be seen as porting the latest Etoys to a different base image
> - one with no Etoys present.
> 
> #3 and #4 are going to be difficult  no matter what, but they might be
> a bit easier if #1 and #2 have already been accomplished.
> 
> I don't have loads of spare time either, nor even the expertise in
> this area of the image. But I, too, would be willing to help. I think
> that achieving #4 is probably the most valuable thing we could put our
> collective effort into, now that the legal and social issues are
> largely fixed. Once our technical issues - of which Etoys is by far
> the largest - are sorted out, we'll be in a very good position to
> progress and grow as a community.
> 
> Colin
> 
Milan and Colin:
I do the rip of Etoys (my way) some time ago.
Also have some success in reloading again an have old Etoys .pr working.
I exchange some email  with Yoshiki and following his advice...
This days I looking how to made a Monticello version from Etoys 4.0 and the
load this into my SqueakLightII, which is a 3.10 shrinked version full
compatible
So if we could work together could be very nice .....
Y puede ser un equipo bilingue, dos de tres entendemos español.

Edgar