As of 0.8.0-alpha.4, the PubSub message deliveries are not Acked by the subscriber. TCP itself could suffice the delivery or message safety requirement for most cases, but I would like to make it configurable for the cases where explicit Ack is preferred. The proposed implementation is like follows
Proposal
There will be three different AckModes.
AckModeNone, no Ack message will be sent back
AckModeAuto, an Ack will be sent back automatically upon message delivery to the client
AckModeManual, instead of receiving Result<Topic::Item, Error> from the Subscriber stream, the user will receive Result<Delivery<Topic::Item>, Error> from the Subscriber stream. The message content (Topic::Item) can be obtained by calling the .ack() method on the Delivery<_> object.
A ClientBuilder will be added where the AckMode can be configured, and AckModeNone will be the default if the AckMode is not configured. Below shows the proposed example usage
// Configure `AckMode`
let builder = Client::builder() // `AckModeNone` is set by default
.set_ack_mode_none() // this will explicitly set the `AckMode` to `AckModeNone`
.set_ack_mode_auto() // set the `AckMode` to `AckModeAuto`
.set_ack_mode_manual(); // set the `AckMode` to `AckModeManual`
After the builder is configured, use the builder to dial to the server. The usage from this point on for AckModeNone and AckModeAuto will remain the same as before. Thus the code below will only show the proposed usage of AckModeManual
let client = builder.dial(address).await.unwrap();
let subscriber: Subscriber<Topic, AckModeManual> = client.subscriber::<Topic>(cap).unwrap();
while let Some(result) = subscriber.next().await {
let delivery = result.unwrap()
let item = delivery.ack().unwrap(); // item is of type `Topic::Item`
// .. do something with the item
}
Progress
In no particular order
[x] Code cleanup
[x] Add type state to Client and Server
[x] Verify AckModeNone just works with existing tests and examples
Why?
As of 0.8.0-alpha.4, the PubSub message deliveries are not
Ack
ed by the subscriber. TCP itself could suffice the delivery or message safety requirement for most cases, but I would like to make it configurable for the cases where explicitAck
is preferred. The proposed implementation is like followsProposal
There will be three different
AckMode
s.AckModeNone
, noAck
message will be sent backAckModeAuto
, anAck
will be sent back automatically upon message delivery to the clientAckModeManual
, instead of receivingResult<Topic::Item, Error>
from theSubscriber
stream, the user will receiveResult<Delivery<Topic::Item>, Error>
from theSubscriber
stream. The message content (Topic::Item
) can be obtained by calling the.ack()
method on theDelivery<_>
object.A
ClientBuilder
will be added where theAckMode
can be configured, andAckModeNone
will be the default if theAckMode
is not configured. Below shows the proposed example usageAfter the builder is configured, use the
builder
to dial to the server. The usage from this point on forAckModeNone
andAckModeAuto
will remain the same as before. Thus the code below will only show the proposed usage ofAckModeManual
Progress
In no particular order
Client
andServer
AckModeNone
just works with existing tests and examplesAckModeAuto
AckModeManual
struct Delivery { .. }