[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [business-transaction] Email votes - 7 Issues - Ends Tues April 9
Bill Your vote on > > - Issue 107: Reply to CONFIRM_TRANSACTION if all is ok > > > NO It seems counterintuitive to have a successful > > CONFIRM_TRANSACTION get a message conditioned on whether > > "report-hazard" is true. A success is not a HAZARD. If we want to > > change the name of report-hazard to > > > "be-really-really-wordy-and-tell-me-everything-I-might-possibly-wa > nt-to-know" > > then this solution makes sense. :-) The thought was that it depends on whether the terminator is in the loop in sorting out a muddle (rather than hazards being dealt with separately, by management action, human intervention etc). Setting "report-hazard" to false means (and I think it says this somewhere) that the terminator is asking to be informed of the *decision*, not of its eventual application. The original application logic may not be able to cope with the multifarious possibilities of hazard, in which case it's reasonable that it be able to say it doesn't want to be bothered with being told. (I'm not sure how happy I would be with an ATM screen that came up with a message: "Something went wrong with the attempt to debit your account. It may or may not have been debitted, or may have been debitted repeatedly. We are not giving you any cash though." I'd rather it said "transaction failed", and told the bank systems to sort things out, involving humans if necessary. Peter
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC