Basic tenets of what goes in the image (was: [Squeakfoundation]Flow integration)

[Daniel Vainsencher]

Hmm, I think it's clear we're not all on the same page here, and I think
we better address this sooner rather than later.

This is my proposed base policy on what should go into the image
* Has to help all Squeakers. Being cool (Connectors) doesn't cut it -
that can live on SM. TestRunner ENHs encourage more SUnit tests, so they
might go in.
* It has to be stable. There is no reason now to integrate unstable
code. Young code can live on SM until it's tested. If package
maintainers prefer it to what's in the image, let them depend on it.
This has two benefits -
 - Acceptance in the community is not binary - you can have users, even
many, before the code is in the image.
 - The use and testing will make the code stable, at which point, we can
put it in the image.
* It has to be understandable. Add class comments, reduce class
count/size, reduce functionality to the minimum that really needs to be
in the image. Just keep it simple.

If we let things in the image that make it bloated, or unstable, or even
stable but unmaintainable, we're eating the goose. I think if we're
commited to making Squeak viable in the long term, we need to keep these
things as high priorities.

At the same time, to help people that contribute work to squeak to know
where to aim, I think we must make the criteria clear, whether we agree
they are similar to the above or not. I reviewed the Mission Statement
now, and it doesn't say much about it, which I think is a bug.

I'd like comments on this at least from all Guides.

Before we decide how to get there on any specific package, we need to
make it clear where we're going.

Daniel

Andreas.Raab@gmx.de wrote:
> Hi Guys,
> 
> > I'm not qualified to answer about the benefits of the new primitive
> > interfaces, I'm quite ignorant in these things. John M has (IIUC) spoken
> > in favor of it. Could we get some more input from the experts?
> 
> From what I can see looking over the primitives, there are two things
> missing. One is support for socket options and one support for security stuff in
> file access. Both are not hard to add but can be painful if missing.
> 
> That said, two extra thoughts. For one thing, it'd be nice to have a version
> that doesn't put 82 classes into "reorganize me" - makes it really hard to
> grok this stuff for someone who has no idea how to reorganize flow ;-)
> 
> Secondly, I am scared to death about the issue of backward compatibility. I
> urge you to consider leaving the current streams and sockets basically intact
> and rather have flow be an _alternative_ to instead of a _replacement_ of
> the current classes. From what I can see there are only very few places
> affected where global names collide and if that's the entire problem someone ought
> to be able to come up with a few alternative names. With the current version
> of flow you will instantly break any code that - for example - uses
> "FileStream readOnlyFileNamed: 'foo.bar'" or "Socket newTCP" (and believe me, there are
> plenty of those in Croquet and if you need another instructive example just
> try to install flow two times ;-) I can understand that providing a full
> compatibility layer in flow may be neither doable nor desirable but that's only
> another argument for leaving the current classes intact to the point that
> there is at least a chance of running existing code. The entire situation here
> strikes me of being amazingly similar to the backward compatibility issues with
> modules - in both cases fundamental notions are being replaced instead of
> augmented. Let's try hard not to repeat this debacle.
> 
> Cheers,
>   - Andreas
> 
> > (This is a draft I think we should post to the squeak-dev to generate
> > the main discussion there. If you guys have comments/additional issues
> > to raise...)
> > 
> > As I noted before, a few people have requested that the Flow work by
> > Craig be integrated into the base image.
> > 
> > This work:
> >  - Replaces the primitive interface to sockets and other External
> > Resources
> >  - Refactors the stream hierarchy
> > 
> > I've had a few concerns that the changes might create too much change
> > all at once, considering that many things use the stream hierarchy.
> > After speaking to Craig about these issue, it seems that (Craig, please
> > correct me if I'm wrong here)-
> > 1. The new streams implement all the old protocols, so that the main
> > compatibility problem should be direct references to the old class
> > names. This is easy to fix incrementally for packages, and fairly
> > quickly for the image itself.
> > 2. The package as it is now can coexist with the existing libraries,
> > making testing quite feasible at low risk.
> > 
> > So I guess this move should be pretty easy. Open questions -
> > 1. Should we do it?
> > 2. How do we test to minimize risk?
> > 3. When?
> > 
> > 1. Do or not?
> > If people know of any general objections/problems with this code, it's
> > best to put them in the open now.
> > 
> > I'm not qualified to answer about the benefits of the new primitive
> > interfaces, I'm quite ignorant in these things. John M has (IIUC) spoken
> > in favor of it. Could we get some more input from the experts?
> > 
> > About the stream refactorings, I think several people have used Flow to
> > develop their own applications. Luciano has mentioned that he's used it
> > for several and liked it. More evaluations would be useful here.
> > 
> > 2. Testing
> > As to format, Craig has agreed to post these changes on SM in the
> > precise form he'd prefer to issue the proposed updates. As to how to
> > make sure it doesn't cause problems for this or that package or
> > application - that's up to you guys out there that use your sockets for
> > more than reading mail... ideas?
> > 
> > 3. When?
> > Probably not in 3.4 (just to keep the release finite and near), but
> > possibly in 3.5. This depends on Craig posting on SM in the proposed
> > format, and mostly on when we get enough testing input.
> > 
> > Daniel
> > _______________________________________________
> > Squeakfoundation mailing list
> > Squeakfoundation@lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> > 
> 
> -- 
> +++ GMX - Mail, Messaging & more  http://www.gmx.net +++
> NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
> 
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation