<div style="font-family: Arial; font-size: 14px; ">One question - and sorry that I didn't get a chance to try some examples myself - but can bi-directional conversations be carried between server/client in interleaving fashion using your library? Something like (simplified):</div><div style="font-family: Arial; font-size: 14px; "><br></div><div style="font-family: Arial; font-size: 14px; ">myClient = receive >>= send . compute</div><div style="font-family: Arial; font-size: 14px; "><br></div><div style="font-family: Arial; font-size: 14px; ">I have previously accomplished this using TBMChan and cereal-conduit to achieve the message delineation, but your library would certainly remove a layer of complexity if interleaved bi-directional talk is possible.</div><div style="font-family: Arial; font-size: 14px; "><br></div><div style="font-family: Arial; font-size: 14px; ">- Ozgun</div><div style="font-family: Arial; font-size: 14px; "><br></div>
<div></div>
<p style="color: #A0A0A8;">On Monday, February 25, 2013 at 8:09 AM, Nils wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>Of course you don't have to use my library if your library already </div><div>solves the same problem.</div><div><br></div><div>Am 25.02.2013 13:10, schrieb Alexander V Vershilov:</div><blockquote type="cite"><div><div>data Result = Error Text ByteString | NeedMore (ByteString -> Result a)</div><div>| HaveResult a</div></div></blockquote><div><br></div><div>I still see an issue with this if you're receiving multiple messages in </div><div>one `ByteString` chunk. A type like `HaveResult a ByteString` which also </div><div>returns the leftover `ByteString` after the first result has been found </div><div>could solve this, but you'd still have to re-yield this bytestring by </div><div>hand and you'll possible end up with more calls to "decode" than necessary.</div><div><br></div><div>Of course, with json you could avoid this problem by wrapping all </div><div>messages into a json-list and sending this list as one big message. But </div><div>that way you lose almost all advantages of a conduit - you cannot map </div><div>over those list iems, you cannot process each item one by one, you </div><div>cannot fold or filter them. When using this approach I don't really see </div><div>the advantage over using the plain old "connectTo/hGetContents" method?</div><div><br></div><div>Anyway, my library is independent of the "bytestring encoding" you want </div><div>to use with it. I think it's the most general solution and avoids having </div><div>to re-implement the same solution for each and every "protocol design" </div><div>over and over again.</div><div><br></div><div>_______________________________________________</div><div>Haskell-Cafe mailing list</div><div><a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a></div><div><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>