From: Walden Mathews <waldenm@optonline.net>

Date: Fri, 10 Jan 2003 09:36:09 -0500

To: Assaf Arkin <arkin@intalio.com>

Cc: www-ws-arch@w3.org

Message-id: <006e01c2b8b5$9dc01dc0$1702a8c0@WorkGroup>

Date: Fri, 10 Jan 2003 09:36:09 -0500

To: Assaf Arkin <arkin@intalio.com>

Cc: www-ws-arch@w3.org

Message-id: <006e01c2b8b5$9dc01dc0$1702a8c0@WorkGroup>

arkin, > > > state, and a write operation to change it to a new state, with guarantee > > > that the same write given the same initial state would always result in > > the > > > same terminal state (in other words, all actions are idempotent). > > > > That may be a deterministic finite state machine, but it's not what > > idempotent means. You should check your definition. For this discussion, > > it obviously matter... a lot. > > Walden, > > Perhaps I don't understand correctly. The definition of idempotent is > "repeated applications have the same effect as one", or "Acting as if used > only once, even if used multiple times." [1] Ok. "Repeated applications" doesn't mean you reset initial state prior to each one, though. > > Given the same input the action I describe above would produce the same > output. And you can continually feed it the same input and it will > invariably produce the same output (in their terminology decide on the same > value). Where I come from, that's called a "function". If "outcome" space is limited to one result, it's "deterministic". Right? > That's not an option. For the action to be used in such a system it > needs to observe these restrictions otherwise everything comes tumbling > down. Right: indeterminism and reliability are a bad mix. That's intuitive. > > So if you do it once, twice or n times, you get the same result. Which is > idempotent as far as I understand it. That's right, as long as each iteration begins with the post state of the prior one. That's what you were missing above when you said "the same write given the same initial state would always result in the same terminal state". Compare these two formulas (1) f(x) = f(x) = f(x) ... = f(x) (2) f(x) = f(f(x) = f(f(f(x) ... The first illustrates "function". The second illustrates "idempotence". [Now that I've had coffee and am feeling pedantic, here's another formula. Guess what REST method property it illustrates (3) f(x) = x] Does the above clarify? If initial state is called x, and the post-state of the first application of the operation "f" is x', then the key to understanding the difference between "function" and "idempotent" is that the latter is saying f(x') = f(x). No matter that x' and x may be the same values. > > What you pass in the input is the state (identifier) you start with and any > thing that has to happen to that state (that's how these protocols work). > Obviously it will only work if the action is still at the same state, but if > it's in a different state it would inform you without doing anything. And > you can repreat sending the wrong state identifier and continue getting the > same result. Not sure about "obvious". You have to design it that way. The system "works" when an application from any state from x' on is a no-op, with the understanding that those states are all identical, but (usually) distinct from initial state x. ["safe"] - did you guess? WaldenReceived on Friday, 10 January 2003 09:36:16 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Tuesday, 3 July 2007 12:25:13 GMT
*