Api V2 suggestion (:

I briefly mentioned this to @cprezzi and he mentioned @tbfleming might anyway be revamping this for his new UI work, but i figured let me write up what i kinda need (using lw.comms-server in another frontend more config orientated) and see what you guys think before i forge ahead with my needs and this never makes it into lw.comm-server (;

Right now - my old legacy way of doing that has stuck inside lw for too long, has been to send individual websocket events for position, queuecnt, etc - very inefficient. in the frontend we have to listen for various named ws events...

I propose we convert to a single object that gets sent over as a single websocket event. Data binding to a single object and then just updating UI when a key changes is more efficient and easier to debug:

Here's what i have so far

var statusjson = {
  machine: {
    overrides: {
      feedOverride: 0,
      spindleOverride: 0
    },
    position: {
      work: {
        xWpos: 0,
        yWpos: 0,
        zWpos: 0,
        aWpos: 0,
        eWpos: 0,
      },
      machine: {
        xMpos: 0,
        yMpos: 0,
        zMpos: 0,
        aMpos: 0,
        eMpos: 0
      }

    },
    temperature: {
      t1temp: 0,
      t2temp: 0,
      bedtemp: 0,
    },
    firmware: {
      type: "",
      version: "",
      date: ""
    },
    configuration: {
      x_steps_per_mm: 0,
      y_steps_per_mm: 0,
      z_steps_per_mm: 0,
      x_acceleration: 0,
      y_acceleration: 0,
      z_acceleration: 0,
      x_max_rate: 0,
      y_max_rate: 0,
      z_max_rate: 0,
      x_axis_length: 0, // Max lenght of axes: Used for soft limits in grbl and smoothie - also maybe useful to autodraw grid size
      y_axis_length: 0, // Max lenght of axes: Used for soft limits in grbl and smoothie - also maybe useful to autodraw grid size
      z_axis_length: 0, // Max lenght of axes: Used for soft limits in grbl and smoothie - also maybe useful to autodraw grid size
      x_homing: 0, // 0 = none, 1 = min, 2 = max
      y_homing: 0, // 0 = none, 1 = min, 2 = max
      z_homing: 0, // 0 = none, 1 = min, 2 = max
      x_home_invert: 0, // 0 = none, 1 = inverted
      y_home_invert: 0, // 0 = none, 1 = inverted
      z_home_invert: 0, // 0 = none, 1 = min, 2 = max
      x_dir: 0, // 0 = normal, 1 = inverted
      y_dir: 0, // 0 = normal, 1 = inverted
      z_dir: 0, // 0 = normal, 1 = inverted
      x_current: 0, // grbl-lpc and smoothie
      y_current: 0, // grbl-lpc and smoothie
      z_current: 0, // grbl-lpc and smoothie
      tools: {
        bed: true, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        e0: true, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        e1: false, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        laser: false, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        spindle: false // not really scoped to configure from here... but rather used in frontend to configure showing options related
      },
    }
  },
  comms: {
    connectionStatus: 0, //0 = not connected, 1 = connected, 2 = playing, 3 = paused, etc?
    runStatus: 0,// 0 = init, 1 = idle, 2 = alarm, 3 = stop, 4 = run, etc?
    queue: 0,
    controllerBuffer: 0, // Seems like you are tracking available buffer?  Maybe nice to have in frontend?
    interfaces: {
      supportedInterfaces: ['USB', 'ESP8266', 'Telnet'],
      ports: portsList,
      activeInterface: "",
      activePort: "" // or activeIP in the case of wifi/telnet?
    },
  },
  logEntry: "String" // In electron we lose the cmd log - can we also emit the log lines here?
};

So basically, in server.js, everywhere where there now is an socket.emit, that gets replaced with a updateStatus(key, value) that updates the object, and triggers an emit of the entire object?
Or we could emit the object on a loop every couple ms?

[tbfleming]

I like this.

Yay! (:

PS: Feel free to add more data as you guys see fit / need too~!

[tbfleming]

Instead of a single work offset, it'd benefit mill and lathe to have the entire set of offsets: G54, G55, ..., G92, G43, and which work offset is active. The normal UI would hide most of these, but it'd be available to custom SVG UIs.

[tbfleming]

To improve efficiency, might have to just send fields with changed values.

Great! That works for me too! Love where this is going!

changed values is fine too (: - at the end of the day in my frontend i still have a single object to worry about

[tbfleming]

As part of the new control UI, I've been pairing down com.js to only talk to the server and not handle any UI issues. It leaves the UI to UI components.

[cprezzi]

I don't realy see how this one big object could simplify the whole thing. If we pack everything in a single websocket event, the client has to parse the object to find out what to do. This also could lead to a performance issue.

I think it's very convenient and easy to attach functions to specific events (like status changes, response to commands, error events) to handle specific tasks. Sure, there is room for cleanup all the events, for example group together all position or status changes, but I wouln'd pack everything in one single ws event.

Or did I understand you wrong?

[tbfleming]

There's exactly 1 event in the react-redux world for communicating system state changes: the store changed, triggered by dispatch(). It lets us pretend that the component tree regenerates the entire DOM from scratch whether a single data item changed, or whether there are massive changes. It greatly simplifies updating the UI; there's no "if state changed from X to Y" code that can miss cases. There are optimizations that greatly reduce the cost, but they rely on diffing immutable objects using identity, not handling separate events.

[tbfleming]

The updated com.js translates between the V1 protocol and the react-redux way of doing things. It's loaded with code like this that I could axe if we switch to @openhardwarecoza 's proposal:

        socket.on('serverConfig', data => {
            this.setComAttrs({ serverConnecting: false, serverConnected: true });
            let serverVersion = data.serverVersion;
            this.setComAttrs({ serverVersion: serverVersion });
        });

        socket.on('interfaces', data => {
            this.setComAttrs({ serverConnecting: false, serverConnected: true });
            if (data.length > 0) {
                let interfaces = new Array();
                for (let i = 0; i < data.length; i++)
                    interfaces.push(data[i]);
                this.setComAttrs({ interfaces: interfaces });
            }
        });

        socket.on('ports', data => {
            this.setComAttrs({ serverConnecting: false, serverConnected: true });
            if (data.length > 0) {
                let ports = new Array();
                for (let i = 0; i < data.length; i++) {
                    ports.push(data[i].comName);
                }
                this.setComAttrs({ ports: ports });
            }
        });

And for me, still to lazy to learn React, the same thing works nicely with Jquery http://www.lucaongaro.eu/blog/2012/12/02/easy-two-way-data-binding-in-javascript/

Right now i also pipe the various "events" into populating that object i want anyway, and from there its go time

Other advantage: To get more diverse frontends to maybe try out comm-server (focus being on making it even less LW connected and more its own thing) - the need to document the API becomes a lot less, since there is only one status event to subscribe to.

Conversely we could probably make the server side more efficient eventually too by sending the UI side events to it in a similar fashion