Julian Sedding wrote > Hi Carsten > >> Offline discussions don't make it transparent why you came to this >> conclusion. >> Please enclose the relevant information either here or in the issue. > > Sure, I thought that I included some information both in the email and > in the issue. But it is probably worthwhile to expand on it a bit > more. > > The current implementation is based on a convention rather than a > contract: place a node under a specific parent node and the JCR > installer will pause its activities. > > It turns out that this convention in this simple form has limitations > when things go wrong: > > - If a "deployer" implementation fails to delete the pause-marker node > (no matter what the reasons are), whose responsibility is it to delete > this node to recover the system? > - If a "deployer" on cluster node A creates a pause-marker node and > then cluster node A is shut down/crashes/disconnects, whose > responsibility is it to delete this node to recover the system? > > Both these questions require a more sophisticated convention IMHO. > This becomes a burden for implementers, makes fixing the convention > nearly impossible (in case we miss an edge case) and is brittle, > because "deployers" may have bugs in their implementations. > > So the logical conclusion is to move the implementation of this > "convention" into Sling and expose it via a simple API. > > The convention basically becomes an implementation detail, which is > needed to distribute the information about blocking the installer > within a cluster. > > Does this answer your questions? >
Thanks, yes, however :) I can't follow the conclusion. How is having an API which for example has a pause/resume method to be called different/easier/avoiding the problems than adding/removing a node? Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
