Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider building a singleton for connection management #16

Open
steel opened this issue Oct 16, 2017 · 2 comments
Open

Consider building a singleton for connection management #16

steel opened this issue Oct 16, 2017 · 2 comments
Milestone

Comments

@steel
Copy link
Member

steel commented Oct 16, 2017

  • Reuse as many connections as possible
  • Multiple requests to the same channel should not create more requests
  • Better error handling
  • Better multi plexed long polling support
@steel steel added this to the v2 milestone Oct 16, 2017
@steel steel mentioned this issue Nov 7, 2017
4 tasks
@adam-h
Copy link
Collaborator

adam-h commented Nov 8, 2017

@steel How do you propose the API would work?

Currently we have (currently - pseudo ish code):

let myConsumer = new FirehoseConnection(channel, options)
myConsumer.on("data", doStuff) //similar for old callback style
myConsumer.on("failed", showError) //similar for old callback style
// ... later
myConsumer.disconnect()

How are you thinking of managing:

  • Connecting to an already connected channel (some other piece of code connected)?
    • I guess we'd need to store the mostRecentMessage and re-send that to the new client(s)
  • How to handle disconnection requests?
    • Some kind of reference counting perhaps
  • Connection options (e.g. multiplex (I don't want different consumers, I'd like this to be an option passed in when you connect) and longPollFirst (I hope to change the default to websocket))
    • For multiplex maybe some kind of Map with keys "channel:multiplex" and "channel:singleplex" - or we just follow the first requestors option?
    • For longPollFirst maybe we just follow the first requestors option?
    • We also have a "params` option which is passed in the query string (websockets) or body (long poll) - how would that work?

@steel
Copy link
Member Author

steel commented Nov 8, 2017

We should disable the option of even not using multi-plexed connections. WebSocket connections are always multi-plexed.

I imagining this simple reference tracker and garbage collecting system

class Channel
  constructor: (name, @wsConnection) ->
    # event handlers string: [handler functions]
    @handlers = {}
    @name = name
    
     # connect to channel
     @wsConnection.send "subscribe", name
     @wsConnection.on "message", @handleMessage

  remove: ->
    @wsConnection.send "unsubscribe from channel"

  on: (event, handler) ->
    @handlers[event].push handler
    @trigger "addListener"

  off: (event, handler) ->
    # remove from table
    @handlers[event][handler] = null
    @trigger "removeListener"

  handleMessage: (channel, msg) ->
    if channel == @name
      # iterate through handlers and call them with the message
      @handlers["message"].forEach (fn) -> fn(msg)
    
class Firehose
  constructor: ->
    # channels is a map of string to Channel objects
    @channels = {}

  bind: (channel) ->
    # look up if channel is exists or not
    channel = new Channel(name)
    channel.on "removeListener", @pruneChannels

    # if channel doesn't exist, create one and connect it
    # then put it in the lookup table

  pruneChannels: ->
    # iterate through channels and remove channels that have no listeners
    
# In a view

# get access to this channel
channel = Firehose.subscribe "my/channel"
channel.on "message", handleMessage

# when removing the view
channel.off "message", handleMessage

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants