<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">3. We want update/delete to be immediate and we'd want any task in progress to discontinue as soon as<br>
possible.  Basically, error out. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">4. Image these tasks queued up [SYNC][SYNC][SYNC][DEL] ... we'd waste a ton of cycles syncing a repo that the<br>
user wants to delete.  And, the delete get's delayed by hours.  Not what the user intended.<br></blockquote><div><br></div><div>I assumed the opposite. If I issue 3 syncs and then a delete, I wouldn't expect the syncs to be canceled. If we do decide to go with synchronous update/delete, we have to account for the possibility that the content adapter has been modified or removed through the whole sync and publish process. I think that would force us to disallow (or just a strongly worded note) warning them not to reload or save content adapter instances, or else they will be susceptible to race conditions. Because the plugin writer is now responsible for handling race conditions and failing gracefully, I I am thinking that it will not be simpler.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">2. Getting a 201 on a resource delete/update seems odd from the REST point of view.</span></blockquote><div><br></div><div>Yeah :( <br></div><div><br></div><div>I am -0 on synchronous calls at the moment but I could be convinced otherwise. I think of this primarily as balancing predictability vs performance.</div></div></div></div>