I can manage the following in a different way (and maybe someone tell me what a better architecture/approach might be), but:
I have a process with a ::flow/in-ports where an external process can make a put of [:get-current-time _response-channel_]. Where response-channel is a channel that the external process wants its response.
This will enter the flow and could be routed to a process which is capable of posting the response. Is there a design reason why response-channel cannot be a key to the output of transform? i.e. a coordinate could be an :out, [pid inid] , ::flow/report or a channel?
Seems fine?
I haven't tried it yet, because the documentation doesn't seem to cover this case: >
Output can be sent to none, any or all of the :outs
> enumerated, and/or an input named by a [pid inid] tuple (e.g. for
> reply-to), and/or to the ::flow/report output.
[{:type clojure.lang.ExceptionInfo
:message "can't resolve channel with coord"
:data {:coord #object[clojure.core.async.impl.channels.ManyToManyChannel 0x6be504dd "clojure.core.async.impl.channels.ManyToManyChannel@6be504dd"]}
:at [clojure.core.async.flow.impl$create_flow$reify__11638$write_chan__11688 invoke "impl.clj" 131]}]
that ManyToManyChannel is a channel that I've passed in from outside the flow.Sorry I missed the bolded part, are you saying a literal channel?
a literal channel
Then no, that’s not supported in the transform result map
On one hand, I can see it would be subverting the well-defined nature of the flow. On the other I don't see it being much different to the [pid inid] pattern, which as a value passed in for a callback is opaque (albeit a coordinate within the flow); what else, in principle, would make a literal channel different?
The whole point of flow is that the flow handles the channels, you handle abstract ins and outs via names