-- This way we don't have to worry about losing the lambdas that go with outstanding method invocations.
Also, don't listen to reload signals except from App (not from third-party DDP servers.)
Can now publish subsets of documents with something like this:
Meteor.publish('items', function (sub, params) {
return Items.find({user_id: params.user_id},
{fields: {some_secret_field: 0}});
});
where items.some_secret_fields won't be included in the publish output.
(fields option is ignored by minimongo.)
Publish now comes in three flavors:
* Bare metal API: Meteor.publish(name, func).
Server will call func(sub, params) each time a client subscribes to
"name" (with supplied "params"), or if "name" is null, each time a new
client connects (autopublish). "sub" is a Subscription object, which
supplies sub.set(), sub.unset(), sub.satisfies(), and sub.flush()
methods to emit DDP data messages. func() should register a cleanup
function with sub.onStop(), which will be called when client unsubs.
To react to database changes, use Collection.observe(). Publish
functions that are not database backed may use some other mechanism
(setInterval?) to schedule calls to sub.set().
* publishCursor API:
If func() *returns* a Cursor, server will automatically publish all
results from that cursor as the collection with the same name as the
cursor's underlying Mongo collection. For example:
Meteor.publish('top10', function (sub, params) {
return Players.find({}, {sort: {score: -1}, limit: 10});
});
will define a 'top10' publish that is always the top 10 scoring
players, published to the 'players' collection on each subscribing
client.
* autopublish
When the autopublish package is loaded, all Collections defined on the
server will automatically be published, in their entirety, to each
connected client. Clients need not call Meteor.subscribe(). Calls to
publish() will emit a warning message, since they are superflous. To
disable autopublish, run "meteor remove autopublish".
