Topics don't support reconnect

[stepmuel]

In our development process, we have to restart the rosbridge quite a lot, and reloading the whole web app every time is a big hassle. So I came up with a way to automatically re-advertise and re-subscribe to topics upon reconnecting to the rosbridge:

function refresh(topics) {
  // resend advertise / subscribe messages
  // http://robotwebtools.org/jsdoc/roslibjs/current/core_Topic.js.html
  for (var i=0; i < topics.length; i++) {
    var topic = topics[i];
    if (topic.isAdvertised) {
      rosBridge.callOnConnection({
        op: 'advertise',
        id: topic.advertiseId,
        type: topic.messageType,
        topic: topic.name,
        latch: topic.latch,
        queue_size: topic.queue_size
      });
    }
    if (topic.subscribeId) {
      rosBridge.callOnConnection({
        op: 'subscribe',
        id: topic.subscribeId,
        type: topic.messageType,
        topic: topic.name,
        compression: topic.compression,
        throttle_rate: topic.throttle_rate,
        queue_length: topic.queue_length
      });
    }
  }
}

I just keep an array with all the topics I'm using and call refresh(topics) on close, which works pretty well. However,

1. The refresh function duplicates code from Topic.js and I would like to refactor that part as readvertise or _advertise so the same code can be reused.
2. Unless this is considered an edge case, Ros should handle the refresh by keeping a list of all topics and doing an automatic refresh on close.

Please let me know what you think. I'd especially appreciate your input regarding naming the functions before I create a PR for (1).

[T045T]

Automatic reconnection sounds neat :)
I don't think we even need a list. Instead, why not give Topic (and Service) listeners to the close event, so they can re-send their subscription/advertising messages themselves?

[Faibk]

I did a quick implementation of the resending of subscriptions by the Topic on close of the connection, but I ran into an issue: The close event is also emitted every time a connection attempt fails. That leads to multiple callOnConnection() entries if the connection cannot be restored on the next try. Is there a way to prevent multiple identical callOnConnection() entries?
Is the close event even supposed to be emitted without a connection established (feels like there should be only an error event on a failed connection attempt)?

[aozisik]

@Faibk
You might want to check out our wrapper around roslibjs that provides auto connection recovery.
It also keeps topics subscribed all the time and thanks to a recent PR, it is smart enough to try reconnecting once regardless of how many times the close / fail events are fired.

http://github.com/milvusrobotics/roslibjs-client

[Faibk]

Your wrapper works well, but unfortunately it did not fit my use case. The wrapper changes the way the roslib is interacted with from an instantiation/object oriented model to kind of a factory model. We have a lot of code already implementing the vanilla roslib approach and built some mechanisms utilizing it. Also we try to keep the dependencies count low, so the needed changes would have been to many.

I built the features into the roslib core and made a pull request: #267