don't send messages back to the author

[AD7six]

It seems quite .. wrong that a message sent from a user needs to go to the server, and back before the author sees the message appear. This implies a lot more traffic than necessary, and also means the author does not see the result of their action immediately - they are delayed by the time it takes for the data to go to the server and back - which depending on their connection could be a noticable delay.

Rather than use the most simple case as before, these changes don't send message back to the author - they rely on the client side js for that and only send messages to /other/ users present in the appropriate room

[tommedema]

When a selector API has been included this would make more sense, rather than iterating over each client to check if it doesn't match the user's client id.

[dvv]

I really can't see why the author is "privileged"? The server could decide to censor the message, spell-check it, whatever before broadcasting. When you drop in a postbox a letter which is addressed to you yourself, do you expect it pops out back to your hands immediately?

[AD7six]

Well, I don't see why the author (in the context of this example) should wait for network latency * 2 to see their messages appear in their chat history.

Why build in that behavior; Other participants won't notice if a message is delayed, even significantly delayed - but the author will. Anything short of Instantaneously adding their own activity to what they see makes the application seem slow.

[dvv]

Curious, if the server rejects (or performs any other action meaning failure in delivery) the message, what do you do at the sending client? The non-authenticating non-authorizing non-db-backed chat example written in now.js is for sure a cool app. But wonder if you could give some other use cases of the simplest one-client exclusion, really...

[AD7six]

Isn't your question about failure-in-delivery a known disadvantage to how pub/sub works? If I wanted to notify the author their message was rejected from the server - I'd issue a new message to the author telling them that from the server.

below where I say message - I mean a packet-of-data, not a chat message :)

General example: using a server side pub sub mechanism allows transmitting messages to different clients (yes, obvious) but for messages which don't need to leave the browser you can use a client side pub sub mechanism (e.g. one of the many jquery pub/sub plugins) to eliminate the potential for latency-delays and also 1/2 or eliminate (in the event they're alone) the traffic involved with the author issuing a message. If nowjs is being used in a transient way (no db on the server) and only a single user is connected to a particular group - there's no need for any network traffic at all since they are only sending messages to themselves - which they can do without the need of a server in the middle. This is essentially how I'm using nowjs.

Specific example: A real usecase for me is: users transmit their mouse movements to a group for some actions, they don't need to receive these messages themeselves as they can see where their own mouse is. Same for every action because even if the js does need to action the same events - the event is sent directly, not via the server. Not sure if that's the sort of example you wanted ;).

[dvv]

Perfectly valid cases, thanks for sharing ;)

[tommedema]

Shouldn't this be closed by now?

[AD7six]

maybe - closed by which commit or closed by what reject-resolution?

[tommedema]

Hi AD,

While this may be an improvement, my reasoning would be that a flawed approach is being 'corrected' by an approach that has it's own problem. This problem is that you create a function, only to be used by the server side, and yet expose it to the client-side (this is the filter function).

This is an integral problem of now.js, which should be fixed when selectors are there.

I guess it could be accepted though, if people think that exposing server side only functions to the client is OK if they are not harmful. Personally I think the only reason this is done is because of a lack of selectors.

[AD7six]

Oh I didn't mean (infact none of my pull requests for any project make this assumption) that the code as presented should be accepted.

But this ticket points out something which should be improved - and a ticket shouldn't be closed without the underlying reason being addressed - But afaik (at least in public) there hasn't been a discussion on how to handle sending events to yourself and avoiding the server - or how to have access to now on the server without unwittingly exposing a function on the client.

AD

[steveWang]

I want to say this is now unnecessary with the release of v0.7, which implements exclude() for groups (among other things). You can now do the following: everyone.distributeMessage = function (msg) { everyone.exclude([this.user.clientId]).now.receive(this.now.name + ": " + msg); };

[tommedema]

@SteveWang, great. Wondering though, are you sure it's best to pass client ids rather than just references to the actual clients?

[steveWang]

It's certainly debatable. Although when are you going to have a bunch of references to clients? If, say, you wanted to get the subset of users in group A not in group B, you could simply do groupA.exclude(Object.keys(groupB.users)). Which is certainly more convenient.

[AD7six]

@steveWang long-awaited change - but the example in now.js doesn't use it.

[steveWang]

One of our goals is to elaborate on our examples, so all in due time. (:

[jeffchan]

:+1: