2

I'm currently implementing a DDP client based on the specs available on this page: https://github.com/meteor/meteor/blob/master/packages/livedata/DDP.md

I just have a doubt concerning the 2 method types called "ready" and "update".

Let's start with the "ready", according to the spec:

When one or more subscriptions have finished sending their initial batch of data, the server will send a ready message with their IDs.

Do this mean that we can have several "added" messages from the server until the whole collection to be completely transferred to the client. We should store this in a temporary place to then wait for the "ready" semaphore prior to make it public ? i.e. in the real collection ?

The same question regarding the remote procedure calls. Should I store the result in a temporary collection and only return (process) the result once the "updated" message is received ?

This part is obscure

Once the server has finished sending the client all the relevant data messages based on this procedure call, the server should send an updated message to the client with this method's ID.

"Should", so I'm stuck if I do rely on it but nothing ?

Flavien Volken
  • 19,196
  • 12
  • 100
  • 133

1 Answers1

6

We should store this in a temporary place to then wait for the "ready" semaphore prior to make it public ? i.e. in the real collection ?

The standard Meteor JavaScript client makes added documents available in the client collection as they come in from the server. So if, for example, the collection is being displayed on the web page and 5 of 100 documents have arrived so far, the user will be able to see the 5 documents.

When the subscription "ready" message arrives, the subscription on the client is marked as "ready", which the client can use if they're doing something that needs to wait for all the data to arrive.

Whether you want to wait in your client for all the data to arrive before making it public is up to you... it depends on what you're doing with your client and if you want to show documents as they arrive or not.

"Should", so I'm stuck if I do rely on it but nothing ?

The Meteor server does send the "updated" message, so you can rely on it.

The same question regarding the remote procedure calls. Should I store the result in a temporary collection and only return (process) the result once the "updated" message is received ?

There are two outcomes from making a method call: the return value (or error) returned by the method (the "result" message), and documents that may have been inserted / updated / removed by the method call (the "updated" message). Which one you want to listen to is up to you: whether it's important for you to know when you've received all the document changes coming from the method call or if you just want the method return value.

The "updated" message is used by the Meteor client to perform "latency compensation": when the client changes a local document, the change is applied immediately to the local document (and the changes will be visible to the user)... on the assumption that the changes will likely be accepted by the server. Then the client makes a method call requesting the change, and waits for the updated documents to be sent from the server (which may include the changes if they were accepted, or not, if they were rejected). When the "update" message is received, the local changes are thrown away and replaced by the real updates from the server. If you're not doing latency compensation in your own client then you may not care about the "updated" message.

Andrew Wilcox
  • 1,021
  • 6
  • 8