Lex Spoon napsal(a):
> We used to consistently have SMTPSocket, HTTPSocket, etc., all
> subclasses of Socket.  Yes, *consistently*.  Then the *Client stuff got
> introduced, but without fully updating the major Internet applications on
> SqueakMap.  There was a long period where Scamper and Celeste did not
> work, and until today, we still have the inconsistencies you describe. 
> For some reason, this "cleanup" project ended up making quite a big
> mess!

This is where packaging system with side-effect of isolation and 
identification comes in place. If networking will be package with clear 
borders and clear assignment that version X.Y is responsible for this, 
that and that functionality (class X, Y, Z), then hopefuly this won't be 
happening often regarding to ability to load/unload package.

> My take: if you want to embark on a cleanup expedition, be prepared to
> do it all the way.  Write updates for all the major packages using the
> functionality, deal with a transition period where both old and new
> names work, and eventually be a good sport and actually get rid of the
> old names as planned.  It's a *bad* thing to submit a renaming changeset
> and do nothing else.  It adds bugs, and I'd rather have things work than
> have things be named in the best way.

Sure, this is what package correlation should solve. Debian does very 
nice job in this. If packages will be in sync it should be working. But 
I feel we have so much obsolete stuff we just can't go in progress and 
keep everything working.

> Personally, major cleanups are usually way too much effort.  I find it much
> better to save cleaning for when I am working on that part of the system
> for some other reason.  I am expecting to break stuff anyway, so I may
> as well try to tidy things up a little while I am there.  If I'm not
> working on the code, though, then why bother cleaning it?  Working,
> debugged, time-proven code is extremely valuable!

In this way there's consequence coming from something like "I would 
abandon this obsolete stuff because it is done better by this class(es) 
but no, what if is someone is using it. I leave it for sure". I don't 
object this is way of life, I just miss here some _art of design_. 
Something kept simple, clear and stable.

>>- leave it as it is and just keep that mess arround. Of course, pray 
>>someone won't write IMAPClient or XYZClient derived from Object and 
>>pissing all this concept.
> 
> Yes, leave it alone.  Why is it so bad if this concept gets destroyed? 
> IMHO, I am not convinced it will really work, anyway: I am not sure that
> line-orientedness is a good enough reason to use up your one chance for
> a superclass.  But it doesn't matter what I think, because Smalltalk
> lets us evolve our concepts over time.  We don't *have* to stick with
> any particular approach if it is not working.  People can make Client's
> that are a subclass of the telnet protocol class, and they can make
> Client's that aren't.  They can even change their mind later.

Sure we can do *anything*. But isn't there something fundamental what 
should be left after us? Sure it might be refactored in future, but it 
must be like crystal ball. I want to send ping and receive pong? I use 
ICMPSocket. I need to communicate with other side sending data forth and 
back? I use ProtocolClient. I need to send and receive data 
simultaneously? I use DuplexProtocolClient or whatever.

I can easily get stuck on that I need to for example use SMTP's VRFY 
command and despite the fact that class SMTPClient bears comment "This 
class implements the SMTP (mail sending) protocol specified in RFC 821." 
it simply doesn't. Sure, I will enhance it and while I'm at it, I may be 
having a taste to *complete* it, to be it really RFC complaint. But that 
was not my intention. Is that development platform I can build very 
specific things on?

> People successfully rely on Squeak as a development platform.  Your
> theory is differing from practice.  

I also do. But in *practice* I needed to tell in one application if 
server has _refused_ my connection attempt (IMCP mesage) or the request 
to connect just _timed out_. I didn't find a way how to. When I got deep 
inside socket stuff I started to learn how is it implemented, what 
primitives are called, why I can't get the real error code. Then I 
started to browse VM's sources, but I ran away a fairly long way from 
what I was doing and what I wanted to do.
I'd be very glad to contribute in spare time. But also want make such a 
contribution real sense. To be used as solid basement, not just 
someone's experiment or just-needed tackle.

-- 
Kamil