Peter Schuller wrote:
> 
> > This is something I personally want. Is it something that might get added
> > to "standard" Squeak?
> 
> I'll assume the answer is no then :)

Well, you did only give it three days, over a weekend, when everyone
was terribly busy yacking about plugin security and whether or not
it's evil to allow non-block arguments to #ifTrue:ifFalse.  :)

> What's the policy regarding the Squeak standard API? What are the criteria
> (if there are any besides the relevant maintainers approval) for getting a
> change included?

There really aren't any formal criteria.  Among the factors which
increase your chances are putting tags like [ENH] in the subject line,
and having people voice a positive response to your work.  It also
helps for the timing to be auspicious.

> And also, is there some architectural reason why polling design patterns are
> used in Squeak? For example, I personally feel a blocking I/O support in
> ConnectionQueue is something that should be standard. Yet the current
> ConnectionQueue only supports a polling API (something I'd never use if I
> didn't have to).

Personally, I think your change to allow blocking requests to
ConnectionQueue is a great idea.  (A method to stop serving new
requests without destroying the queued connections would be nice,
too.)  In fact, the entire Socket interface could use similar changes.
I'd like to see a more stream-like interface -- although perhaps
something simpler than flow; I just couldn't seem to get my head
around that.

As for the polling design patterns are used so much in Squeak, I
imagine it's largely historical.  It appears that these things *have*
been getting better lately.

-Jesse