You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our application we may need to keep a routing table (Map (S.ByteString, Int) Connection) and so reuse connections. But implementation of it requires execClient to take Connection as argument.
Is it acceptable to create following functions: execClientWithConn :: Client a -> StateT Connection IO a initConn :: ByteString -> Int -> IO Connection closeConn :: Connection -> IO ()
and put them into Network.MessagePack.Client.Internal?
The text was updated successfully, but these errors were encountered:
Write execClientWithConn :: ClientT m a -> StateT Connection m a to allow IO wrappers.
Add an export list to the Internal module, because you're going to export that module now, and we don't want to expose more than necessary. You may need to restructure things a bit, because currently the Internal module is written with the idea that it won't be exposed in the library. E.g. we still want the Connection type to be opaque.
Add a comment to the top of the now exposed Internal module that its API is unstable (in reality, the rest of the API is also unstable until release 1.0, but for internal stuff it makes sense to be more explicit about it).
In our application we may need to keep a routing table (
Map (S.ByteString, Int) Connection
) and so reuse connections. But implementation of it requiresexecClient
to takeConnection
as argument.Is it acceptable to create following functions:
execClientWithConn :: Client a -> StateT Connection IO a
initConn :: ByteString -> Int -> IO Connection
closeConn :: Connection -> IO ()
and put them into
Network.MessagePack.Client.Internal
?The text was updated successfully, but these errors were encountered: