Re: Descending replication

[Garren Smith]

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 
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 
> 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

[Robert Samuel Newson]

Hi,

I agree this would be a great option, even a better default.

B.

> On 4 May 2017, at 14:21, Johannes J. Schmidt  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
>