Re: Descending replication
What is the next step for something like this? I'm guessing a github ticket would be great. What kind of internal changes would be required? On Thu, May 4, 2017 at 10:22 PM, Robert Samuel Newson <rnew...@apache.org> wrote: > Hi, > > I agree this would be a great option, even a better default. > > B. > > > On 4 May 2017, at 14:21, Johannes J. Schmidt <schm...@netzmerk.com> > wrote: > > > > Hi! > > > > I'm cross posting this issue from the PouchDB project: > https://github.com/pouchdb/pouchdb/issues/6480 > > > > > > # Descending replication > > > > I'd like to discuss an idea that came up during Offline Camp: descending > replication. > > > > Initial replication performance is still an issue, it's intrinsic to > huge data sets. > > > > When you initially replicate its often the new data that's the most > interesting to the user. And that one arrives at latest. It would be good > to be able to replicate in descending order. That way the user would see > new data instantly, while the rest drops in later. > > Also, the app could decide to stop replication at some point based on a > memory limit. Sometimes you don't want to sync an entire dataset (for > example for event based data). > > > > Descending Replication would give us: > > > > 1. Relevant data first (improved UX) > > 2. Requests like "Give me 200MB of (latest) data" > > > > Do you see any generic problems? Wouldn't this be an easy change? > > > > Relax, > > Johannes > > > >
Re: Descending replication
Hi, I agree this would be a great option, even a better default. B. > On 4 May 2017, at 14:21, Johannes J. Schmidt <schm...@netzmerk.com> wrote: > > Hi! > > I'm cross posting this issue from the PouchDB project: > https://github.com/pouchdb/pouchdb/issues/6480 > > > # Descending replication > > I'd like to discuss an idea that came up during Offline Camp: descending > replication. > > Initial replication performance is still an issue, it's intrinsic to huge > data sets. > > When you initially replicate its often the new data that's the most > interesting to the user. And that one arrives at latest. It would be good to > be able to replicate in descending order. That way the user would see new > data instantly, while the rest drops in later. > Also, the app could decide to stop replication at some point based on a > memory limit. Sometimes you don't want to sync an entire dataset (for example > for event based data). > > Descending Replication would give us: > > 1. Relevant data first (improved UX) > 2. Requests like "Give me 200MB of (latest) data" > > Do you see any generic problems? Wouldn't this be an easy change? > > Relax, > Johannes >
Descending replication
Hi! I'm cross posting this issue from the PouchDB project: https://github.com/pouchdb/pouchdb/issues/6480 # Descending replication I'd like to discuss an idea that came up during Offline Camp: descending replication. Initial replication performance is still an issue, it's intrinsic to huge data sets. When you initially replicate its often the new data that's the most interesting to the user. And that one arrives at latest. It would be good to be able to replicate in descending order. That way the user would see new data instantly, while the rest drops in later. Also, the app could decide to stop replication at some point based on a memory limit. Sometimes you don't want to sync an entire dataset (for example for event based data). Descending Replication would give us: 1. Relevant data first (improved UX) 2. Requests like "Give me 200MB of (latest) data" Do you see any generic problems? Wouldn't this be an easy change? Relax, Johannes
