[prev in list] [next in list] [prev in thread] [next in thread]
List: haskell-cafe
Subject: Re: [Haskell-cafe] ANN: conduit-network-stream, A base layer for network protocols with Conduits
From: Ozgun Ataman <ozataman () gmail ! com>
Date: 2013-02-25 15:49:46
Message-ID: 3E51EBAF0AD442D4A0C1FF0DF089C1CB () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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):
myClient = receive >>= send . compute
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.
- Ozgun
On Monday, February 25, 2013 at 8:09 AM, Nils wrote:
> Of course you don't have to use my library if your library already
> solves the same problem.
>
> Am 25.02.2013 13:10, schrieb Alexander V Vershilov:
> > data Result = Error Text ByteString | NeedMore (ByteString -> Result a)
> > > HaveResult a
> >
>
>
> I still see an issue with this if you're receiving multiple messages in
> one `ByteString` chunk. A type like `HaveResult a ByteString` which also
> returns the leftover `ByteString` after the first result has been found
> could solve this, but you'd still have to re-yield this bytestring by
> hand and you'll possible end up with more calls to "decode" than necessary.
>
> Of course, with json you could avoid this problem by wrapping all
> messages into a json-list and sending this list as one big message. But
> that way you lose almost all advantages of a conduit - you cannot map
> over those list iems, you cannot process each item one by one, you
> cannot fold or filter them. When using this approach I don't really see
> the advantage over using the plain old "connectTo/hGetContents" method?
>
> Anyway, my library is independent of the "bytestring encoding" you want
> to use with it. I think it's the most general solution and avoids having
> to re-implement the same solution for each and every "protocol design"
> over and over again.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org)
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
[Attachment #5 (text/html)]
<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>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic