search

arunoda / meteor-smart-collections

Meteor Collections Re-Imagined
MIT License
147 stars 13 forks source link

Latency Compensation and Write Fence #18

Closed arunoda closed 11 years ago

arunoda commented 11 years ago

See related discussion with David Glasser

latency compensation (the write fence): Meteor methods (such as the auto-generated insert/update/remove collection methods) have two different "done" messages. One is the "result" message which contains the method's return value or error, and is delivered as soon as the method body returns or throws. The other is the "updated" message, which specifies that any writes done by the method have been reflected in data messages (added/changed/removed/etc) sent from server to client. The latter method is what links together the two components of DDP (methods and data). If any collection write happens in a method body, then by use of an object called the Write Fence, we ensure that the "updated" method does not get sent until all possibly-affected cursors have been polled one time. The client uses this message to prevent flicker (ie, latency compensation): essentially, any documents that are modified by the client-side stub are "frozen" until the method's "updated" message shows up, at which point we should have seen the final value of the documents.

arunoda commented 11 years ago

Implemented in branch: writefence-support Not completely tested yet.

No Support for update/remove by selector This is very hard to implement with oplog enabled

arunoda commented 11 years ago

published with 0.3.13