Some thoughts:
It doesn't really help with any of the "standard" recipes as they all need to
set watches. Not to open a can of worms, but if there were a firehose version
of watches that could be set independently, this type of multi-op could
radically simplify some of the recipes. i.e. one could imagine a multi-op that
creates an ephemeral node and then returns a sorted list of child node names so
that leader election and locks can be done in one shot.
An atomic counter could be done much more simply than how Curator does it now
as the test/increment could be done server side
Queues would be easier (possibly - I need to think about this some more).
Curator's queue code is very complex.
Anyway - I'll try to spend some time in Curator's various recipes to see how
they would be simplified if this server-side feature was available.
-Jordan
> On Aug 16, 2019, at 11:51 AM, Ted Dunning <ted.dunn...@gmail.com> wrote:
>
> The recent discussion about if/then/else idioms in ZK has raised the
> thought that it might be nice to have some extended semantics.
>
> One version that I could see would be to to extend the current multi-op to
> allow multiple alternatives. The idea would be that there would effectively
> be multiple branches to be tried. The first one that succeeds atomically
> (all or nothing) would be used. The returned value would need to somehow
> indicate which alternative succeeded and would need to return any data
> accessed. The testing of alternatives would also be atomic so it wouldn't
> be possible for things to change within a single operation.
>
> This extension would allow the previous question to be answered like this:
>
> pick_first {
> create(...)
> } {
> set(...)
> }
>
> (the syntax here is just made up and wouldn't actually be supported ... it
> is just for pseudo code purposes).
>
>
> My theory is that this would be relatively easy to implement based on the
> current multi operation. Risk due to the change is pretty low given that
> there is code to copy.
>
> My question is whether this would actually have all that much benefit.
>
> Does anybody have an opinion on that?
