Skip to content
This repository has been archived by the owner on Dec 12, 2024. It is now read-only.

Consider splicing Close into two separate semantic use cases #255

Closed
KendallWeihe opened this issue Mar 5, 2024 · 3 comments
Closed

Consider splicing Close into two separate semantic use cases #255

KendallWeihe opened this issue Mar 5, 2024 · 3 comments

Comments

@KendallWeihe
Copy link
Contributor

KendallWeihe commented Mar 5, 2024

From here:

Do we allow Close after Order but before OrderStatus?

I'm going to work under the assumption the answer to that question is no. If the answer is yes, then it weakens my points below but nevertheless I'll make them 😃

There are 2 overarching phases of an exchange:

  1. Negotiation (RFQ and Quote)
  2. Execution (Order and OrderStatus)
@KendallWeihe
Copy link
Contributor Author

KendallWeihe commented Mar 5, 2024

Under the consensus of #242 we could have a Close in both of the 2 phases describe in the description.

Example 1

Alice: RFQ
Alice: Close (whoops jk, don't send me a quote)

Example 2

Alice: RFQ
PFI: Quote
Alice: Order
PFI: OrderStatus x n
PFI: Close 

My argument is, using Close across both phases is a semantic conflation which will serve to confuse the DX. A confusion which will be further exacerbated by the rule "Close can't be sent after an Order"; meaning, a Close can be sent across both phases, but only at certain points within each given phase.

One may approach tbdex and first see that a Close can be used to cancel an active negotiation and solidify that in their mind, only to later come across, "oh so that message is also used at the end of every exchange regardless of the result." So it's the same name for two distinct semantic use cases.

The two use cases being:

  1. To cancel/reject an active negotiation
  2. To establish the execution as completed (no further messages may be sent)

Furthermore, I think it's slightly a confusing DX for the PFI to define their set of OrderStatus's which at first glance would logically include a COMPLETED status, but then also have to include an additional Close (another semantic duplication).

Working on a proposal, will publish in a subsequent comment 😃

@KendallWeihe
Copy link
Contributor Author

Haven't forgotten about this, but have had my hands full

The TL;DR will be that we can implement a new message type called Cancel and then still use Close. Cancel will be for terminating during the Negotiation phase, and Close will be for the execution phase.

Two additional thoughts:

  1. Can we send a Close after an Order but prior-to an OrderStatus
  2. There's still a slight semantic duplication across the PFI-defined OrderStatus which represents a completed state, while also required the terminating Close message (diagram below to illustrate this -- IMPORTANT: disregard this being a proposal, as I'm not sure what the solution to this would be, if there even is one)

image

@mistermoe
Copy link
Member

mistermoe commented Mar 8, 2024

There's still a slight semantic duplication across the PFI-defined OrderStatus which represents a completed state, while also required the terminating Close message (diagram below to illustrate this -- IMPORTANT: disregard this being a proposal, as I'm not sure what the solution to this would be, if there even is one)

resolution to ^ here: #258 (comment) and here: #242 (comment)

thanks for all of the effort you put into driving discussions about this @KendallWeihe ! going to close this one out for now. feel free to re-open with narrow scope if/when further discussion is needed

@mistermoe mistermoe closed this as not planned Won't fix, can't repro, duplicate, stale Mar 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

2 participants