On 12 August 2012 09:04, Colin McCormack <colin@...> wrote:
> Striving to find meaning in this post, in order to rebut what gives the
> appearance of being its conclusion ...
That's only because you've already reached your conclusion.
To begin with: My argument is, and always has been, we need UDP
support NOW, it's long overdue already. But we also need something
better than what we have, which isn't available yet, and nor should it
be rushed. The idea of creating a brand new new command that WILL be
obsoleted just as soon as possible, simply isn't the right way to go.
Make no mistake that BOTH these solutions are hacks. Mine, however,
can be re-implemented without leaving a permanent wart behind.
> On 12/08/12 03:02, Fredderic Unpenstein wrote:
>> Oh ghod. Not another future legacy command. Entire ideas have been
>> quashed because they introduce a new command, and rightfully so.
> Citation Required. I am unaware of any idea which was squashed
> *because* it introduced a new command.
Oh, it's not written in any document that I'm aware of. It's in the
herding mentality of the elitists. They're important, of course, they
have the skills TCL needs, but they sometimes forget what it's like to
be a normal person, trying to grasp a new language. Part of this, has
an attempt to remind those same people of that, and to remind them
also of arguments past that are being ignored here. Dig deep enough
through the history here, and you'll find plenty of examples.
A new command should only be added if absolutely necessary, and of
sufficient general use. A [udp] command is neither.
>> [puts] is for output, [read] is for input, [socket] is for networking,
>> and [fconfigure] is for configuring.
> [puts] and [read] provide stream input and output, that is
Actually, that' is exactly what I am disputing in this point, and you
too, within this very paragraph of yours. But for now, why is [puts]
and [read] strictly stream related? The "s" in puts stands for "put
string", not "put stream". I see no conflict.
So is it because that's what we're used to? Someone new to the
language isn't. To them it's a new command, with whatever nature the
designers of the language gave it. Part of their job is to figure out
where it fits into their existing concepts that such a command name
suggests. So maybe it's YOUR mind that you're objecting to changing,
it's YOU (and others with the same opinion) that doesn't want to have
to deal with having to change your perception of these commands. Is
it because that's what the documentation says? Documentation can be
changed. What other solid reason is there? I agree "puts" isn't the
best name for a non-stream writer, the "s" could be mistaken for
"stream" instead of "string". But we do the best with what we have.
> Stream input and output are a kind of input and output,
> that is obvious.
And packet input and output are a kind of input and output, what's
that got to do with anything? My argument is that [puts] and [read]
are input and output commands. Whether that's stream or packet, is
immaterial, and quite frankly, bikeshedding.
And hence my opening statement. My input was to try and help resolve
a bit of a conundrum; we need something done, in less time than we
have to do it. The solution then, is to use what we have now, and do
> The only controversial part of this set-up is the
> implicit, unevidenced, and in fact provably false assumption that all
> input and all output are stream input and output. That is, of course,
> what the author is trying to demonstrate. It is, of course, far easier
> to demonstrate anything when one assumes it to be true at the outset.
I think you've just proven my point in the very first sentence.
"assumption that all input and output are stream input and output". I
totally agree with you, that is a wrong assumption. And any
suggestion of that should be stripped from our perception and the
documentation. The implementation reflects that that is simply is the
way it's been up until now, there simply hasn't been anything else the
I/O mechanism has had to handle. But that too is merely
short-sightedness, not proof of anything particularly useful.
>> Yes people will try to use
>> [gets] and other stupid things, that's what you write "Please don't do
>> this" in the documentation for. But it should work, none the less. A
>> packet is a buffer is a file. When you reach the end of the packet,
>> you throw EOF.
> The author appears to confuse 'packet' with 'datagram.' The two things
> aren't identical. A datagram under UDP/IP may comprise many packets.
> This confusion over networking does not bode well.
It's called a simplification. The extra detail is neither needed, nor
relevant, and only serves to fragment the intention. Again, this is
not intended to be a complete solution, so yes there will be
compromises involved, and no it won't be the final iteration.
Whatever the naturally useful granularity of the protocol, regardless
of transport details and so forth, that is what I was referring to as
a packet, not some level of abstraction chosen to suit your particular
argument. And I haven't yet seen a good reason why this isn't
sufficient for all but the very most esoteric uses, just as the
existing I/O mechanism isn't sufficient for all conceivable uses
either. As someone else pointed out, TCP streams support a few
features not represented by the existing TCL infrastructure -
hopefully the next one will fix that. Perhaps, fixing that might even
provide an insight on how to better implement UDP support in its next
form. But that brings us back to needing something usable for the
majority of situations now, and in a reasonably obvious fashion.
>> I hear people talking about all these nasty edge cases, but very
>> little mention of any real situations that can't be dealt with.
> Merely because something can be 'dealt with' it does not imply that
> thing is desireable, otherwise I guess we'd be lining up around the
> block to get cholera.
And I made no suggestion otherwise. But we already have an
undesirable situation; a lack of UDP support in core. And to follow
your analogy, until a cure is available, medication will have to do.
>> knows there were plenty in TCP support, that have been sorted out
> There have been historical mistakes, and so we should create more? I
> find this argument unconvincing.
And yet I find that to be exactly what is being suggested; a new [udp]
command that is a confused mixture of old and new patterns, when a
mechanism exists and will suffice just fine in the interim. Donal's
OOP will hopefully provide a fantastic foundation for the next I/O
mechanism, and adding a new [udp] command is simply going to create
more legacy rubish. By the same token, NOT adding UDP support, will
also encourage another premature half-baked solution.
>> And being able to put the socket into buffering mode so you can
>> compose the datagram, and then [flush] to write as a packet, is a
> It's not a convenience, but a necessity if you confuse a continuous
> stream of output with a puncutated series of datagrams. It's hard to
> see how the requirement to perform at least two operations to transmit a
> datagram is more convenient than having to perform one. It would seem
> less convenient.
I've already answered that. The default, would be to perform just one
action, as you say. The alternative, accumulation followed by an
explicit flush, allows a single value, the "stream name" (as it is
presently referred to), to be passed through function calls in one
direction. The single-action mode, requires the value be passed in
the opposite direction (if not in BOTH directions), or a mechanism be
built to provide for that feeding backwards. This idea simply allows
you to choose the direction that suits your situation, rather than
forcing you to change your situation to suit the tool. There are of
course pros and cons to that, too, but I've yet to see a solution to
any problem that resolves ALL situations in which the problem arises.
>> Maybe a bad one, but so be it. You use [fconfigure] to
>> target return packets, a default of buffering=none lets the
>> application build the packet, and send it with a single write. A
>> specific buffer size will throw an error if you overrun it (instead of
>> blocking), and disable auto-flushing entirely. THAT is what a basic
>> implementation should aim for; with little more than what we already
>> know and love, it just works. If you need more, better, advanced,
>> it'll come later.
> Nobody is arguing that it's impossible to emulate UDP over a stream.
> The argument is that, while possible, it's a bad idea.
And once again, I quite agree. I've been arguing to use the
interface, not the mechanism. I don't want UDP to be streamed. I
think it would be good for completeness to make auto-flushing of data
chunks possible; some streams such as the random atmospheric noise
example, don't care if they get divided arbitrary or if chunks come in
out of order or not at all. But that should by no means be default
>> I don't care about this "TCP is for streams" and all the rest, THAT is
> I understand that you do not understand, or do not value, the difference
> between streams and datagrams. I am unsure that this ignorance (whether
> willful or accidental) really forms the basis for a design.
lol Yeah, sure. Just as you seem wilfully ignorant of the
distinction between the interface and the mechanism. The core does
not, and in fact SHOULD NOT be expected to handle 100% of situations.
It IS however, expected to provide a mechanism to handle MOST
situations, particularly those required most often. If you need more
advanced support, that's where a specific or even custom library comes
The call for a [udp] command introduces a new base command for an
uncommonly used protocol. That's a lot of junk that every application
will have to carry. If the internal core mechanism of UDP is done
right, a blessed module can tie into that at the C level to provide a
more comprehensive interface with all the bells and whistles that more
advanced usage requires.
I do agree it is somewhat unfortunate that the [chan] command will
inevitably end up being used on a non-channel protocol, but I see that
as more an unfortunate short-sightedness in the naming of [chan], than
anything else. It has more to do with TCL's internal representation
(something TCL has mostly strived to hide from its users) of
networking, than the actual mechanism being managed. I've felt all
along, that it should have been called something more generically
networky, but a choice was made to make channels the abstraction of
networking, so that's what we have.
It should be pointed out, also, that bytearray's are just as
appropriate in a TCP stream, as they are in a UDP datagram, and
deserve better and more natural support there than they have. We just
need to separate the concept of a communications channel, from a
communicated stream. A channel need not involve a stream at all. So
if you can get your head around that distinction, then it all falls
into place just fine.
>> We have an I/O interface, and everyone knows it,
>> everyone is familiar with it.
> Yes, Tcl provides for I/O. It builds on the C stdio package from
> decades ago. That does not make it an appropriate model for datagrams.
> Of course, nothing prevents people building a chan over a udp
> implementation, should they be so minded, and should they value the
> consequent and inevitable confusion.
Indeed. And as I hope by now I've demonstrated, that has nothing to
do with my proposal at all. I wish to use the interface, not the
mechanism. Please try not to confuse the two.
>> And until a totally new more modern
>> layer is created, ANYTHING done here will be little more than a hack,
>> including some soon-to-legacy [udp] command.
> I don't know what 'soon-to-legacy' means. I do not believe an
> event-based API for UDP to be a hack, but rather an interface which
> faithfully represents the nature of the underlying facility. The
> event-based API does not require any 'more modern layer', whatever that
> might mean (it is not evident from the text.) Mediating events is
> precisely what the event system is for, and UDP packet reception is
> precisely modelled by events.
And in what way is TCL's existing [socket -listen] mechanism not event
based? Receive a connection, invoke a handler. In Tk, events are
handled in the same way, by invoking a handler. That is an event,
this is how TCL handles them. In what fundamental way does this [udp]
command differ, other than in the specific way information about the
event is conveyed?
>> So just use what we've
>> got, don't add anything more than a couple extra -options to [socket]
>> and [fconfigure], and do it right when right becomes a possibility
>> (and with due baking time allowed).
> If I understand the basis for this exhortation, it is: I can't
> distinguish between datagrams and streams, therefore datagrams should
> look like streams for everybody, and those for whom the distinction may
> have meaning should work around my preference.
Your entire argument revolves around "UDP is not a stream". My
argument revolves around interface, perception, utility, and several
other things, none of which involve anything about streams. You're
stuck this one irrelevant track, and sliding towards personal attack
as a means to reinforce your unnervingly narrow view. Perhaps, as the
old saying goes, you've lost sight of the forest for the trees.
> I think the argument from convenience fails insofar as, in my considered
> opinion: the distinction is significant for anyone who actually uses
> datagrams for useful work, and therefore the only beneficiaries of the
> suggested policy of confusion are precisely those who do not use them.
> This does not appear, to me, to be an economic use of the development
> time of the implementors or the developers of UDP facilities for Tcl.
But inventing a whole new single-purpose interface, and then
maintaining it for the next decade or so, is?
Please, put your knowledge where your mouth is, and tell us all about
these concrete specifics of UDP, as related to this "real work" you're
the expert in, that would not be handled by the existing interface,
without mention of "streams" or any other details of the existing
implementation. In other words, tell us all what in UDP, can not be
readily implemented in terms of [socket], [puts], [read], and