On Thu, Jan 29, 2009 at 10:56 PM, Antony Blakey <[email protected]> wrote: > > Extending this to update functions means that conflict resolution is no > longer globally deterministic, because it depends on the propagation pattern > of the update function. Same with validation and authentication. > > This will only affect some use cases, but it's a very difficult problem in > meshes.
Ahh, I didn't consider the validation function as being replicated as well. I suppose I'm imagining that validation functions will define the borders of applications, and thinking of these data flows as within a particular application. This is a straightforward consequence of the fact that design docs are documents just like any other, which of course has so many good effects that it's hard to find fault with the system because of edge cases like this. Another edge case from validation functions (which can happen even on a single node) is that documents which have been added to a db, can be invalidated by the addition of a validation function after they have been saved. Having a view of all newly-invalid docs will definitely be useful. It seems like if you want to ensure that your system follows some of the stricter principles you outlined, you'll have to avoid use of (changing) validation functions in your applications. Or at least be very thoughtful about code roll-outs. This may be a logical fallacy, but finding an "inconsistency" like this, encourages me that we maybe dealing with a "complete" system. I'd rather have something powerful enough to generate inconsistencies than something so meager that it can't. -- Chris Anderson http://jchris.mfdz.com
