Added support for single-user outbound messages

[alberto-schena-gizero]

Hello! Congrats for your work, I really like it!
Can you see any pitfalls with my approach about message unicasting?

[cinhcet]

Hi! Thanks :-)

Could you explain what you want to achieve?

Because the code already has the option of handling ajax requests. With this, the client can make a request to a node and it will be send back to the specific client that made the request.

[alberto-schena-gizero]

My ultimate goal is to deploy a single dashboard for multiple customers.
Within the NR flow run messages regarding different users and customers.
Messages may either come from UI actions or from automatic events.
In such a multi-user scenario, most outbound messages (towards UI) need to be unicast (e.g. for privacy and scalability reasons), and, apart from UI interaction, need to be sent without any client request.

[cinhcet]

Are you sure you can achieve this with the changes you made? Because how do the nodes know to which client to send if there has not been a message received before. Furthermore, the design of this project assumes that each widget has a unique state. For example, the replay messages correspond to each widget and not for different users. It has not been designed with different dashboard states in mind.

There is one reason why I am a bit hesitant to merge this: I want to get rid of socket.io in the near feature and this change makes use of a feature from socket.io.
I need to think about it.

Maybe if you explain a little more how you want to use the socketid.

[alberto-schena-gizero]

The nodes may know the connected clients by means of a "client node" in the flow, with these assumptions:

• yad.js and yad-client-node.js should be modified in order to enrich the "on connect" messages with the _socketid property;
• a new node type may be added for handling "on disconnect" messages as well, which will also provide the _socketid property;
• thus, nodes within the application flow can maintain the list of active socket IDs, optionally mapped by user (e.g. user info may be provided as message properties by the "is logged in" node from node-red-contrib-users used in conjunction with an "http in" route which has to be called automatically by clients at connection time; but maybe even simpler mechanisms or NR modules might exist).

Some sort of replay mechanism (rather like a UI re-initialization, actually) may be achieved by using a "client node" instance triggering the fetch of updated data and its injection into the UI of the newly connected user.

What do you think?

[alberto-schena-gizero]

To simplify the task of mapping each socket ID to/from the specific user details (about capabilities with the UI, and data message pertinence) I'm considering to enrich the "on connection" messages with the socket cookies (which come from the authentication phase). They are exposed by socket.io APIs. So no post-authentication http route to call.

[cinhcet]

just for your information, I am extremely busy at the moment, but I will come back to this.

Is there a reason why you created a new node for disconnect and not handling this also in the current client node?
Because since you removed an existing node, this would never be mergeable, since it breaks backwards compatibility.

[alberto-schena-gizero]

You're right, I didn't think about that.
Absolutely I can switch back to the original "client node" and enrich it with disconnection event messaging.

[cinhcet]

thanks! I don't have time to look into it this week, but it now seems fine :-)