[Squeakfoundation]Flow integration

Andreas.Raab@gmx.de squeakfoundation@lists.squeakfoundation.org
Thu, 21 Nov 2002 22:20:05 +0100 (MET)


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!