So use a mixed approach. Queries are likely best handled by including a return channel with the request.
Updates are likely best handled with a flow approach. Complex queries may involve passing a return channel deeper into the process. Especially notification requests. No one answer is best for all, as usual. But keep simple things simple. Bill On Thu, Jan 7, 2016 at 11:16 AM, Vic Putz <vbp...@gmail.com> wrote: > Thanks to both of you! > > On Wednesday, January 6, 2016 at 10:11:39 PM UTC, tbc++ wrote: >> >> Most would perhaps start with the classic approach of having each request >> contain a :reply-to channel that the responses go into, but I think this is >> a mistake. >> >> IMO, there are two main ways of building systems with core.async 1) >> request/response. 2) dataflow graphs. >> > > I like the dataflow-graph approach, because I don't like the idea of > conflating routing with messages that a "sender" or "reply-to" within the > message requires (though William, I hadn't thought of just putting the > channel itself as reply-to... great idea if I go that route and much > simpler than dropping into pub/sub). So I'd rather the service just > have "in" and "out" channels and have the wiring be done externally > (probably through initialization via "component"). > > And if the components were wired together 1-to-1, that would be dead > easy. I'm just not sure how to deal with a component/service which should > be able to handle multiple in-out connections ... my naïve approach would > probably just be for services to have a vector of in/out connection pairs > that got wired up at initialization and maybe go-loops over all of them, > which would probably work but seems mildly inelegant somehow. > > (again, using the toy application of a jukebox service and three > clients... the clients can't request a song until they know what songs are > available, so bidirectional communication seems necessary somehow; I can't > see how to design a wiring diagram without it) > > -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/_8fHJ3J-MYg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
