|Maintainer||Stefan Schmidt (email@example.com)|
Version : 0.1
General functions for the transmission of messages over the Holumbus-Ports. You don't need these functions, but they make your life much easier.
The mailbox concept doesn't deal with the request and response scheme very well, but with this module, all the boring stuff is solved. The function performPortAction will do everything for you. If you find it boring to write a seperate listener-thread for every mailbox you want to read from, you might look at the startRequestDispatcher and stopRequestDispatcher functions.
- class RspMsg m where
- performPortAction :: (Show a, Binary a, Show b, Binary b, RspMsg b) => Port a -> Stream b -> Int -> a -> (b -> IO (Maybe c)) -> IO c
- startRequestDispatcher :: (Binary a, Show a, Show b, Binary b, RspMsg b) => Thread -> Stream a -> (a -> Port b -> IO ()) -> IO ()
- stopRequestDispatcher :: Thread -> IO ()
- handleRequest :: (Show b, Binary b, RspMsg b) => Port b -> IO c -> (c -> b) -> IO ()
The typeclass for the response messages. We want to react if an error message is received an this interface helps us to detect and create such a message. The unknown message will be send back, if the server doesn't understand our request.
|:: (Show a, Binary a, Show b, Binary b, RspMsg b)|
|=> Port a|
|-> Stream b|
timeout for the response in mikroseconds (1000000 = 1 sec) (0 = wait for ever)
|-> (b -> IO (Maybe c))|
|-> IO c|
Sends a request to the server (stream) and handles the response and all error cases. Very helpful when simulating a request response scheme with the mailboxes.
|:: (Binary a, Show a, Show b, Binary b, RspMsg b)|
threadId, to be filled
|-> Stream a|
request-Stream (this is where the messages come in)
|-> (a -> Port b -> IO ())|
the dispatcher (create a reply message)
|-> IO ()|
The server-side request dispatcher handles all incomming responses. The dispatcher runs in its own thread and should not be killed by any exceptions which will be raised in the handling process.