Re: invertability and idempotence

On Oct 21, 2009, at 6:58 PM, R. David Murray wrote:

> But it turns out that idempotence does have a meaning in the context
> of the email module, so I think I need to remove 'depreciated' from
> my glossary[1] entry for it, and explain what it means in the context
> of the email module.

I think you're onto something here.

> For background, see issue 7119[2].
>
> Here's what I propose: _invertability_ applies to the data path
> into the parser and out of the generator.  That is:
>
>    generate(parse(msg)) == msg
>
> should be true whenever possible.

Agreed, where 'msg' in this context means the message text or bytes.

> On the other hand, when _constructing_ a message, sometimes not all  
> data
> is filled in (in the example above, it is the MIME boundary marker).
> In that case, it is important (I think, please discuss :) that  
> generating
> the message maintain _idempotency_: once you have generated the  
> message,
> then if you have not further mutated the message, generating the  
> message
> again should produce the _same_ output.  That is:
>
>    generate(msg) == generate(msg)
>
> even though the state of msg may change after the _first_ generate  
> call.

"Idempotent" means: "multiple applications of the operation do not  
change the result".  So here where the operation is to take a message  
object and generate a stream of text or bytes, this should absolutely  
return the same stream if the object is not mutated between calls.  I  
think it's fair though that if the model is manipulated in any way, we  
make no guarantees of idempotency, though we should strive for minimal  
differences.

-Barry