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: /services/wordpress/settings /services/wordpress/units/wordpress-0/agent-connected /services/wordpress/units/wordpress-1 /machines/machine-0/agent-connected /machines/machine-0/units/wordpress-1 /machines/machine-1/units/wordpress-0 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 http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter
