Y'all --
After some thought on the entire ownership and subscription issue raised
yesterday in the WG meeting -- to repeat the problem for those who weren't
there... If an application/controller installs state into a particular agent
running on a particular network node, what should we do with
Y'all --
After sleeping on the discussion last night, I think the panes of glass (or
is it pains of glass?? :-) ) is still by and large another expression of
the priority concept within I2RS. The concept does bring up one specific
point of interest, however -- what about backup information? Some
We discussed storing backup ephemeral state. There are a number of
issues that arise if we permit that.
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
> 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
I would indeed expect to use the same mechanisms for delivering the
error notifications as for all other notificaitons.
And I suppose one could allow a client to unsubscribe from such
notifications. But it actually seems to encourage dangerous behavior to
do so. And adds extra complexity.
> 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.)
I don't really see it as "caching..." I'm thinking more of the backup route
On Mon, Nov 2, 2015 at 6:05 PM, Joel Halpern Direct <
jmh.dir...@joelhalpern.com> wrote:
> What we side with regard to the atomicity of collisions was that the model
> needed to specify that. So if the model writer concludes that the leaves A
> and B in your example are so closely coupled that
On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7ri...@gmail.com> 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
What we side with regard to the atomicity of collisions was that the
model needed to specify that. So if the model writer concludes that the
leaves A and B in your example are so closely coupled that bad things
will happen if different people write different parts, then they can say
the
