----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/#review69863 -----------------------------------------------------------
proton-c/bindings/python/proton/__init__.py <https://reviews.apache.org/r/30318/#comment114676> This seems to change the semantics of send in a subtle but odd way. If you pass in something that it knows how to encode into bytes, it will assume that constitutes an entire message and call advance and automatically generate a tag for you. Yet if you pass in raw bytes, it doesn't do this. I think these two things should really be controlled orthogonally, e.g. I might want to be able to configure the sender to assume every call to send is a single message even if I'm just passing in raw bytes, and I might also want to be able to stream large messages out by passing in higher level message chunks that the sender automatically encodes into bytes for me. proton-c/bindings/python/proton/__init__.py <https://reviews.apache.org/r/30318/#comment114674> This could be a bit nicer if we were to check for an encode method or something rather than hardcode an isinstance test against Message. That way I could implement arbitrary objects that can be encoded as AMQP messages. proton-c/bindings/python/proton/__init__.py <https://reviews.apache.org/r/30318/#comment114677> I like having the ability to control tag generation, but again it is odd that this just gets ignored if you happen to pass in bytes. I think in general send(message) vs send(bytes) should have the semantics of simple overloading, in other words the former should be equivalento to send(message.encode()). As you have it the semantics are actually quite different in these two cases. - Rafael Schloming On Jan. 27, 2015, 2 p.m., Gordon Sim wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/30318/ > ----------------------------------------------------------- > > (Updated Jan. 27, 2015, 2 p.m.) > > > Review request for qpid and Rafael Schloming. > > > Repository: qpid-proton-git > > > Description > ------- > > Sending a message requires several steps: create a delivery with a unique > tag, encode the message, cal send(), call advance. While this gives a lot of > flexibility and power (e.g. streaming messages in chunks without ever holding > the entire thing in memory), for many, many use cases, a simpler solution > would be adequate and would avoid users having to learn what is in my view > one of the more esoteric aspects of the API. > > The attached patch adds send support for a Message object, such that a > message can be sent with a single call. It also allows the send() method to > be 'dual purpose'. It remains backwards compatible as a way of appending > bytes to the current delivery, but can also be used as a one-step call to > send a single message. > > At present the engine examples in python make use of a similar > simplification, but one that is added dynamiccaly and is therefore less clean > and obvious. It currently also doesn't work as well for sending on links > established by the remote peer. This addition would in my view allow for > simpler use where needed, without breaking any existing usage. > > > Diffs > ----- > > proton-c/bindings/python/proton/__init__.py 17cef30 > > Diff: https://reviews.apache.org/r/30318/diff/ > > > Testing > ------- > > > Thanks, > > Gordon Sim > >
