I love the idea of core.async channels as generic inboxes for "in-program microservices" for lack of a better term. They're a great decoupling mechanism.
But I get a little confused when you get beyond a producer-consumer model. A service with an inbox (consumer) works well for multiple clients (producers) because they can all just dump data into the same inbox. But it gets a little trickier if you want any data back (toy example: a jukebox microservice with an input channel: drop the song name in as a string and it starts playing, and doesn't care if A, B, or C dropped the song name in, but if A wants a list of available songs you need a return channel and the jukebox can't just drop A's list of songs in a single outbox. Either it feels like you need separate return channels for each client (which complects transport with processing, but would let each client pretend they had a private connection) or you have to use core.async publish-subscribe, maybe pulling "sender" out of the topic for the return address and have clients subscribe to the service's output channel based on their own identifier, but that forces messages to carry extra information about routing... which may be fine. Is there an established pattern or mechanism for this, or is pub/sub probably the best way to go? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
