It doesn't seem like you're trying to perform multiple actions simultaneously. For example, you don't need to be able to read from the server and send data back at the same time. Instead, you'll have a single thread of execution. Am I right?

If so, it seems like the simplest thing would be for you to allow users to write something like:

Conduit MsgFromServer m MsgToServer

Assuming you had conduits to convert an incoming byte stream to a stream of MsgFromServer and the equivalent for sending, you'd end up with something like:

appSource appData $$ toMsgFromServer =$ clientSuppliedConduit =$ fromMsgToServer =$ appSink appData

Michael

On Tue, Apr 9, 2013 at 1:09 PM, Alexander V Vershilov <alexander.vershilov@gmail.com> wrote:

Hello.

I have next problem: I have a network client that connects to server, listens for messages and generate responces. So the control flow can be represended as:

server -- input -> {generate output} -> output

Output can be generated using default implementation or can overriden by user.

The main difficulty appeares when I need to add a user program on the top of this logic,
i.e. from user-side I want to have dsl:smth like

withClient $ do
   x <- send message
   waitFor x
   timeout 5000000
   forever $ sendRandomMessage

i.e. an ability to send messages, waiting for some event (message to come), waiting for
timeout.

The question is how to define such logic without a big overhead. I see a solution using conduit, it's possible to create 3 processes: listener, user, sender.

                         +----> user ----+
                         |                    |
-input -> listener +----------------->+---- sender ->

and use TQueue or TChan to send messages between them, however there can be another possible solutions, that uses less resources, or another design.

--
Alexander

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe