Re: Design Question for Model and View

Kai Schwebke wrote:
By shifting the control to the view[,] the flags and callbacks
can be avoided in this case.

This is a very good principle to enforce between two components - distinguish the initiator ("client") from the responder ("server"), in your case the view and the model, respectively.

The responder should not initiate, thus the initiator need never respond.

The initiator asks the responder if it's "saved". Based on the answer, the initiator might solicit information from the user. Based on that answer, the initiator might ask the responder to save the data. After all that, the initiator asks the responder to close (something).

This pattern avoids a lot of deadlock and complexity, and has surprisingly wide applicability.

--
Lew
.

Relevant Pages

  • Racoon(8) Deleting SPD Entries
    ... but the responder no longer has SPD entries for the pair. ... it tries to send, there is no entry in the SPD, so the outgoing SA is ... On the initiator, ...
    (freebsd-net)
  • Re: Design Question for Model and View
    ... This is a very good principle to enforce between two components - distinguish ... The responder should not initiate, thus the initiator need never respond. ... This pattern avoids a lot of deadlock and complexity, ...
    (comp.lang.java.programmer)
  • Re: Correct response to Aggressive Node if not supported
    ... The closest you can get to that is having the responder ... at least within a single negotiation. ... initiator can offer both in the sense that it can try one (say ...
    (comp.dcom.vpn)
  • Re: IKE Phase1 3 message pair
    ... Why can't the responder look at the IP header?? ... The responder can look at the cookies and/or IP address to to ... but neither the IP address or cookies *authenticate* the initiator. ... That is, the responder can tell it has two connections, but not who ...
    (comp.dcom.vpn)