On Jan 25, 2014, at 3:17 PM, Michał Marczyk <michal.marc...@gmail.com> wrote: > If the application is structured in such a way that messages from the > other side of the client/server divide are put on channels upon > arrival, which seems to be a reasonable idea, why not encapsulate the > connection-handling logic in a black box exposing a (bunch of) > channel(s)?
This is more or less what the core of David's code does: * the code uses regular core.async channels (on both sides) * both side have the concept of a remote channel (which is associated with a GUID in a registry atom) * a "black box" on each side takes from remote channels and sends data across the wire (including the channel ID) * that "black box" also receives data over the wire and puts data onto the appropriate remote channel As far as the application is concerned, it's all just channels - the black box performs relaying of data across the client/server gap for each remote channel. All of the solutions folks have posted so far seem to assume a single channel routed over the client/server transport so I feel comfortable going ahead with library-izing David's code to support multiple channels and, ultimately, multiple transports. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880)
signature.asc
Description: Message signed with OpenPGP using GPGMail
