Hi Mahadev,

>  Usually the paradigm I like to suggest is to have something like
> /A/init
> Every client watches for the existence of this node and this node is only
> created after /A has been initialized with the creation of /A/C or other
> stuff.
> Would that work for you?

Yeah, this is what I referred to as "liveness nodes" in my prior
ramblings, but I'm a bit sad about the amount of boilerplate work that
will have to be done to put use something like this.  It feels like as
the size of the problem increases, it might become a bit hard to keep
the whole picture in mind.

Here is a slightly more realistic example (still significantly
reduced), to give you an idea of the problem size:


There are quite a few dynamic nodes here which are created and
initialized on demand.  If we use these liveness nodes, we'll have to
not only set watches in several places, but also have some kind of
recovering daemon to heal a half-created state, and also filter
user-oriented feedback to avoid showing nodes which may be dead.  All
of that would be avoided if there was a way to have multi-step atomic
actions.  I'm almost pondering about a journal-like system on top of
the basic API, to avoid having to deal with this manually.

Gustavo Niemeyer

Reply via email to