Optimization: customize the publish/subscribe methods

[zeroasterisk]

Is there some way we could customize the publish/subscribe methods for the collection?

In my use case, I only need to monitor messages dependant on a Session variable.

That is, 95% of my clients don't care at all, and wont render/act upon any notifications.

Were this a normal publish/subscribe, I could base the subscribe upon the Session variables.

While the code runs fine, with the Session variable restrictions being handled in the on() handler, it's not optimal. All clients are getting all messages

And yes, I know I can restrict based on the Meteor.userId but in the case of this app, most clients are anon.

[arunoda]

How does this relates to meteor-streams?

This might help you anyway.

[zeroasterisk]

(sry - I accidentally submitted the question too early - just edited)

[arunoda]

Hope this would work.

Notifications = Meteor.Streams('notifications');

if(Meteor.isClient) {
  Notifications.emit('active', true);
}

if(Meteor.isServer) {
  var states = {};
  Notifications.on('active', function(state) {
    states[this.subscriptionId] = state;
    this.onDisconnect = function() {
      delete states[this.subscriptionId]
    };
  });

  Notifications.permissions.read(function() {
    return !!states[this.subscriptionId];
  }, false);
}

Anyway, we need a better and simple easy way to do this. I will add a new API. But not sure about the timeline.

[zeroasterisk]

SWEET! thanks for the plugin, thanks for helping me, and thanks for the ninja-fast response.

As I read this

• no client would be "subscribed" (no messages sent on) until it had sent through the .emit('active', true);
• and once that has happened, other messages would be passed like normal like .emit('sent', 'yup this is sent');
• until .emit('active', false); is sent in by this client

is that correct?

Brainstorming

If mine is an edge case, this should be a sufficient workaround.

The concept of "listening = true/false" seems like a simple enough one to implement (perhaps a slightly cleaner implementation than your above code, but functionally the same). It isn't as versatile/direct as customizing the publish/subscribe, but it is a heck of a lot easier and simpler.

If you think customizing the publish/subscribe "rules" for notifications is a common enough use case, perhaps you could provide default publish/subscribe, allowing developers to manually assign if they had custom rules. (?) Or maybe you could look for a streams.subscribe() method, which could be run on the client to determine if it should subscribe. (?)

[arunoda]

Yes you are correct. You've to do allow write permissions also. If emited from a client

Notifications.permissions.read(function() {
  return true
});

Your suggestion on the API is good. I'll consider it 👍
I'm thinking about new easy to understand API. I'll publish more info as I go through it.