The low-level API just became a lot less attractive when I realized that the listener API for sockets is basically only constructed to work with effects managers.
Mark On Wed, Nov 30, 2016 at 6:45 AM Mark Hamburg <[email protected]> wrote: > We've been building an app that communicates with the server via web > sockets. The server associates account information with the socket so we > don't have to send it repeatedly. We've recently been thinking about how to > handle login to multiple accounts. The proposal that floated up was to > simply open a socket per account. Now, note that we have not yet done so, > so maybe this breaks somewhere else but the APIs everywhere point to it > being feasible. Well, everywhere except Elm. It looks like the Elm Web > Socket API assumes that there will be only one connection per URL. Is this > correct and if so is there a recommended work around? My guess is that the > answer is going to be to move to the low-level web socket API and re-write > the layers above it and that's feasible but I always feel a little dirty > touching a low-level API because it feels like something that exists more > to implement the high-level API than it exists for usage by others, but > maybe that's just a perception thing. > > > Mark > > P.S. Before someone suggests using separate Phoenix Channels per user, > note that we're already using Phoenix on top of web sockets and we're using > channels for other structure within the communication. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
