Allowing caching means that we have to specify additional mechanisms
(such as read-through and write-through, and returns for successful
writes that do not actually take effect, and probably other aspects.)
So we agreed that was for future consideration, as it is by no means minor.
Yours,
Joel
On 11/2/15 8:28 PM, Russ White wrote:
For example, if state gets over-ridden, but preserved, then even though it
is
not doing any good, the client which installed the state must still
monitor for
any related dependenecies so as to not leave incorrect pending state.
Which also means that a client has to be able to remove state it has
created,
even though that state has been over-ridden. And probably has to be able
to create state which won't take effect. Which in turns means that you
need
to be able to read your own effects and the current state separately.
I would think this should be a client specific implementation detail... I
don't see why, from a protocol level, it should be disallowed, when the
changes involved would be minor (or at least it seems to me?).
:-)
Russ
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
