[sorry about the late response, been *very* busy]

> You submit them here.  From time to time they are collected, usually 
> before a new rev is released.  Some get accepted for the core image, 
> some don't.  Some get listed and saved as "goodies," others don't.  Most 
> properly submitted submissions get posted to the Swiki.

Ok. About what my understanding of it was.

> The URL reflects that it was "collected" in the Swiki.  This is as much 
> response as is likely to happen before a version collection.  Usually 
> when fixes are being formally collected, an inquiry goes out for 
> "reminders" that something was overlooked.

Fair enough.
 
> > I suppose my enhancement may have contained a bug / been considered
> > badly written; but I would at least have expected to receive some sort
> > of response.
> 
> Not likely, here or in many OSS projects.

Usually a person submitting a patch is in some way informed of wheather
or not it was comitted by a maintainer.
 
> Not really, although folks do comment as you have from time to time, 
> both here and in many other OSS projects.  Thanks for the contribution, 
> by the way.  As a general matter, this "problem" is going to be obviated 
> after general adoption of the new Module systems, in which every user is 
> empowered to post Modules in the Squeak People path.

Where can I read more about the module system? It sounds like a good
solution. Would this be related to the "virtual root module" window in
the latest 3.3alpha?
 
> That is why they are on the Swiki -- this is one of the primary places 
> for inclusion other than incorporation into the "core image."  There is 
> a strong current prejudice against image bloat, with a focus on 
> refactoring the image for breakout into modules.

I definitely don't want to bloat the image. I'm much for a modular
approach; the monolithic nature of Smalltalk is one of its disadvantages
IMO (although there are also advantages to the image approach).

However, there is lot's of not-strictly-necessary stuff in the image. I
am not proposing that anything I will mention just now should not be in
the image; but if a basic feature such as blocking accepts in the
network support is considered bloat, then surely a 3D engine or a
pluggable web server is even more bloat?

Again, I am not saying I have anything against the 3D stuff or the web
server to be in the image (although a modular approach would be best -
for everything), but the bloat argument doesn't really explain why a
very basic feature like blocking accepts didn't make it into the image.
I mean, we are talking about a feature whose absence in a language like
Java would result in the language being considered severely defective!

Reading my changes now, I can see that I am capable of producing a
better version of it with my current Smalltalk skills. However, I don't
feel particularly inclined to, since I have no indication of why the
original patch was not comitted in the first place. And hence, I have no
reason to believe an updated version would be accepted. And sine the
original ones gets the job done, I don't *personally* need a better
version.

Plus, my original patch is already out there. As a result, there is
potential for clashes unless I change method names just to avoid it. (I
don't particularly believe anyone's actually using my original patch -
but how would I know?).

Another thing I don't like about Squeak's networking with respect to
this is that accepts are done through polling under the hood anyway,
regardless of my patch. This is something I'd like to fix. But it would
probably take me a while (not being an expert Squeak:er). However, I am
reluctant to try since I have little faith that such a fix would be
accepted even if it were to turn out good. And I *don't* want to end up
with 75 private patches that never make it into the official Squeak, and
that I therefore have to keep comitting to my images after every upgrade
- possibly with conflicts every once and a while. (Conflicts are bound
to occur because those 75 patches would be modifying "base" classes.
Other modifications done will be done relative to the officially release
version. If they conflict with my private changes, my changes will break
and I would have to fix it.)

Ah well. Looking forward to that modular system possible making this
easier!

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org