You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
get rid of unused interfaces (no deprecation needed, since these are unused (at least not known to us)):
get rid of SetSendTimeout/GetSendTimeout/SetReceiveTimeout/GetReceiveTimeout (at least from the general interface). Values set by these FairMQSocket methods are currently used only inside each transport - they are transport details. The actual transfer timeouts are controlled by the user via transfer calls, e.g.: Receive(FairMQMessagePtr& msgVec, const int timeout = 0). It is up to the transport how to implement it these. A general timeout value currently has no meaning in the user-facing API.
get rid of GetOption/SetOption and replace with specific API, such as SetLinger/GetLinger. This is less error-prone and more type-safe. Currently these interfaces are only used internally in FairMQDevice for high watermark and kernel transfer size settings.
get rid of general GetSocket interface - it returns internal socket representation, which should not be visible from the interface API.
rename SendAsync/ReceiveAsync to more clear TrySend/TryReceive Remove SendAsync/ReceiveAsync, instead Send/Receive with a timeout of 0 can be used (since these are used, this will require a deprecation warning iteration). This is already the case in the transport API, but not yet in Channel API.
move Bind/Connect/Attach implementations from device class to channel class.
introduce (experimental?) value-based move-only fair::mq::Message in parallel to existing FairMQMessage. As a consequence this will require new overloads for send/receive and serialization APIs.
Anything else?
The text was updated successfully, but these errors were encountered:
get rid of unused interfaces (no deprecation needed, since these are unused (at least not known to us)):
SetSendTimeout
/GetSendTimeout
/SetReceiveTimeout
/GetReceiveTimeout
(at least from the general interface). Values set by these FairMQSocket methods are currently used only inside each transport - they are transport details. The actual transfer timeouts are controlled by the user via transfer calls, e.g.:Receive(FairMQMessagePtr& msgVec, const int timeout = 0)
. It is up to the transport how to implement it these. A general timeout value currently has no meaning in the user-facing API.GetOption
/SetOption
and replace with specific API, such as SetLinger/GetLinger. This is less error-prone and more type-safe. Currently these interfaces are only used internally in FairMQDevice for high watermark and kernel transfer size settings.GetSocket
interface - it returns internal socket representation, which should not be visible from the interface API.renameRemoveSendAsync
/ReceiveAsync
to more clearTrySend
/TryReceive
SendAsync
/ReceiveAsync
, insteadSend
/Receive
with a timeout of0
can be used (since these are used, this will require a deprecation warning iteration). This is already the case in the transport API, but not yet in Channel API.move
Bind
/Connect
/Attach
implementations from device class to channel class.introduce (experimental?) value-based move-only
fair::mq::Message
in parallel to existingFairMQMessage
. As a consequence this will require new overloads for send/receive and serialization APIs.Anything else?
The text was updated successfully, but these errors were encountered: