<br><div class="gmail_quote">2008/5/5 Krzysztof Sobolewski <jezuch@interia.pl>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Marcel Hauf pisze:<br>
<div class="Ih2E3d"><br>
> If I have the protocol library what is left?<br>
><br>
> * Client to server connection, I think I will do this via sockets<br>
> * Configuration, should be easy with xml<br>
><br>
> Have I left something out?<br>
<br>
</div>Well, I have "configuration" in the form of static factories of the<br>
Connection object. I'm not sure it's that much to tweak here. Maybe the<br>
protocol version, but it's parameterized (via generics and the Visitor<br>
object) and not a concern for the library itself.</blockquote><div><br>I thought about the client library (Which form of connection for example).<br>I rethought this and I think it should be handled by the client directly not by the client library.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
As for the connection, the protocol library is basically a way to serialize<br>
frame objects to a stream, so any form of binary stream should do (even<br>
though libtpproto-java assumes sockets; this might be an interesting thing<br>
to take just the in and out streams and not bother with that). And I don't<br>
see an alternative to sockets for network communication... ;)<br>
<br></blockquote></div>Yeah, right but .Net provides a TcpClient class to handle a net connection easier.<br>But I prefer sockets.<br><br>The client library receives binary "code" which will be deserialized by a BinarySerializer with the help of the protocol library.<br>
This means the protocol library must be 100% compatible to the server protocol library, I´m correct?<br><br>~ Marcel Hauf<br>