Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resumable DDP subscriptions #52

Open
3 tasks
raix opened this issue Dec 19, 2014 · 5 comments
Open
3 tasks

Resumable DDP subscriptions #52

raix opened this issue Dec 19, 2014 · 5 comments

Comments

@raix
Copy link
Contributor

raix commented Dec 19, 2014

Its not possible to resume a DDP connection - I'm mainly thinking about pub/sub.

Why?

  • Less data on the wire
  • Better support for offline data caching
  • Perhaps less in memory subscription tracking on the server

Brainstorm:

The server could have a different way to keep track of subscriptions - perhaps the client is better fittet requesting the data not on the client:

The client could tell the server what subscriptions are on the client - this way the server could query the db directly using the publish query on the client, the server time stamp and the resumed publish query.

I'll prop. write a prototype of this since its part of getting ground:db to work better with subscriptions and the iron:router.

  • Add last data server time stamp to all data (could also be used in conflict resolution)
  • Make sub/pub handle data more intelligent using the servertime stamp
  • Make sub/pub intelligent about before / after arguments in the publish

This is not ideal to solve in packages since it requires replacing things in ddp/livedata etc. but thats been the message from @glasser so far:

Regarding server timestamp on ddp handshake: I don't think this belongs as a core part of DDP. You can always add methods (or subscriptions) that return server time. And unlike this PR, which hooks directly into the low level DDP code, that could easily be an Atmosphere package.

Note: The initial code indicating resumable subscriptions were swiped from Meteor approx: a year ago (or something - I havent tracked down a reference, but its part of a clean up by glasser)

Note about resume:

Ref server resume:

Ref about server timestamp:

@mitar
Copy link

mitar commented Dec 19, 2014

It there a message from @glasser missing in the description above?

@raix
Copy link
Contributor Author

raix commented Dec 19, 2014

just added references, and removed the label "MDG dont agree" since its not 100% clear

@mquandalle
Copy link

This could also be used for server side rendering. For instance the server send the 10 first items of a list in the initial HTTP response. Then the client could resume this DDP connection so we don't have to send the same data twice (is that still the case in fast-render @arunoda?).

@arunoda
Copy link

arunoda commented Dec 20, 2014

We don't have any kind of resuming in fast-render but it does do conflict resolving upto some point. If we need to do resumable stuff I think we need to manage changes in a way how git works.

So, that's a big topic.

@mitar
Copy link

mitar commented Dec 20, 2014

If we need to do resumable stuff I think we need to manage changes in a way how git works.

What has git with this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants