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)-
- 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 -
Should we do it?
How do we test to minimize risk?
When?
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.
- 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?
- 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
squeakfoundation@lists.squeakfoundation.org