On Mon, Dec 24, 2012 at 2:58 PM, Glyph <glyph at twistedmatrix.com> wrote:
> In my humble (but entirely, verifiably correct) opinion, thinking of this as
> a "default" is propagating a design error in the BSD sockets API. Datagram
> and stream sockets have radically different semantics. In Twisted,
> "dataReceived" and "datagramReceived" are different methods for a good
> reason. Again, it's very very easy to fall into the trap of thinking that a
> TCP segment is a datagram and writing all your application code as if it
> were. After all, it probably works over localhost most of the time! This
> difference in semantics mirrored by a difference in method naming has helped
> quite a few people grok the distinction between streaming and datagrams over
> the years; I think it would be a good idea if Tulip followed suit.
Suppose PEP 3156 / Tulip uses data_received() for streams and
datagram_received() for datagram protocols (which seems reasonable
enough), what API should a datagram transport have for sending
datagrams? write_datagram() and write_datagram_list()?
(Given that the transport and protocol classes are different for
datagrams, I suppose the create*() methods should also be different,
rather than just having a type={SOCK_STREAM,SOCK_DATAGRAM} flag. But I
can figure that out for myself. The naming and exact APIs for the
client and server transport creation methods are in flux anyway.)
--
--Guido van Rossum (python.org/~guido)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4