_replicate vs _replicator

[mandric]

When doing an install we are using the _replicate api. Using this with continuous:false is blocking, so a response is not returned until replication completes. This can cause connection timeout issue under certain network conditions, especially with large design docs and slow connections. Should we be creating a document in _replicator instead and just query that doc periodically until replication completes?

[ghost]

@ryanramage: Do you have any ideas here (in the context of the @garden20, not medic)?

[ryanramage]

Yes, going with the _replicator db would be a better choice. I think the _replicate endpoint was used initially just to get something running faster.

New changes I would like to see in garden core here:

https://github.com/garden20/garden-core/blob/master/garden-core.js#L52

You could make changes in that project, and make a test case and see if that helps in remote location. My guess is you might want to set continuous to true, because otherwise flaky connections would even set the replication doc in an error state.

So I think create a doc in the _replicator db, annotate it with some install meta data, and then just keep checking if the target doc exists yet.

Those would be my ideas.

[mandric]

How would a continuous replication scenario work? Would we create a continuous replication task and then delete it when it completes? Wondering what happens if client just closes the window for example.. I guess that would be fine. Install would continue and we would would have cancel and delete functions/buttons.

[ryanramage]

I think that if it was not continuous, you would see the same problem. The replication would fail over bad connections, and the replication document would have an error state. So the problem would be the same. Adding continuous gives it more of a fighting chance for retries.

Yes, rethinking how the ui works will be more of a challenge.