On Mon, 21 Apr 2008 22:24:35 BST Charles Forsyth <[EMAIL PROTECTED]> wrote: > > must not buffer data indefinitely, and (2) MUST set the > > PSH bit in the last buffered segment (i.e., when there > > is no more queued data to be sent). > > > > The implication is that the "preceding segment" to a pkt with > > no data *will have* PSH set. > > so does the implementation do that?
Do you mean plan9 after the change? The traces I looked at seem to do that. Others certainly seem to do that. > can you prove it in all cases? Not in the formal sense. Not enough free time or incentive. > what will break if we just change it without knowing? > after all, it has been 15 years to come across a botched receiver's implement > ation > of PSH (ie, godaddy's) which is the only reason to change it. > that's what i was pointing out. i could do the work myself, i suppose, but i > haven't got the incentive. I understand your concern about possibly breaking things with this change. It should certainly be tested more thoroughly but since the change brings Plan9 behavior more in line with what *BSD/Linux/Windows do I am not as apprehensive as you are. > >here you have to be compatible with existing > >implementations as far as possible (in order to maximize > >interoperability). > > i suspect arguments like that caused the current situation with HTML, CSS and > Javascript. > computing is needlessly regressing. May be. Somehow this makes me think of E W Dijkstra :-)
