Start and stop Server-sent events notification

I have 3 Server-sent Events available to a page. Only one viewable at any time. I would like to stop the listener on 2 of the 3 event streams when 1 of them is active. I have a switch statement testing for which is visible but can not pass the source.close() to my event directly as it is buried in a function:

var firstEventSource = function() { 
    var eventSrc = new EventSource('firstSTREAM.php');
    eventSrc.addEventListener('message', onMessageHandler);
};

I was hoping to have fewer open connections to the server, especially with non-viewed data. If you have a 开发者_Go百科better suggestion I'm all ears!

Best,

T

function onMessageHandler(event) {
  if ("your want to close that EventSource") {
    event.target.close();
  }
}

This question is hard to answer without more context, but I'll do my best.

You could think of the event resource as a pipe where you push all of your messages, and have the client listen for specific events, effectively multiplexing:

var handler = console.log.bind(console)
  , events  = new EventSource("/events")

events.addEventListener("new-friend", handler)
events.addEventListener("new-message", handler)
events.addEventListener("new-notification", handler)

This would reduce your connection count to exactly one, and would save you from doing costly reconnects whenever you switch between views. However, it has the drawback of your server pushing (possibly) unnecessary data down the pipe. After all, you're only viewing one message type at a time. You should consider whether this is an actual problem though. If your UI should update, perhaps with some kind of badge notification (like facebook's message or notification icons) then you will need to know about those messages even though the user may not be actively on that particular view. In any event, you should try to keep messages lean for performance sake.

If you can't or won't push all messages down the same pipe, you probably should go with your initial thought of having multiple resources or the ability to query the resource in question, and then opening and closing the connections. Bear in mind though that this could potentially be very costly, as the client could end up hammering the server with requests. Each view change would cause connections to be set up and tore down. It'd look something like this:

/* Assuming jquery is available and with the following html:
 * <a class="stream" href="/friends>Friends</a>
 * <a class="stream" href="/messages>Messages</a>
 * <a class="stream" href="/notifications>Notifications</a>
 */

var currentEvents
  , handler = console.log.bind(console)

$("a.stream").on("click", function() {
    $el = $(this)

    currentEvents && currentEvents.close()

    currentEvents = new EventSource($el.attr("href"))

    currentEvents.addEventListener("message", handler)

    return false
})

In the end, it depends on context. If users aren't going to switch views very often, or the messages are really big, then you might want to go for the second approach. It'll feed less data down the pipe, but create and tear down connections as the user navigates. If the user often switches views however, or you can keep the message size reasonable, then I'd advocate multiplexing, like in the first solution. It'll keep one long-running connection where small messages of different types may be pushed to the client.