--part1_30.2c2a65b3.2aa01c7f_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
> Yes, I agree that open protocols and published specifications are
> great, but you'll want to have a good library on the client side of
> the connection to make life bearable. Otherwise you are stuck parsing
> every bit of data on your own. This is not HTTP and using something
> like XML as the transfer protocol would be a mistake.
>
True- I have no desire at all to see XML here. However, if the bulk of
communication uses SQL statements, we are not looking at a terribly complex
transaction to query the database. Even HTTP protocol can get ugly, and its
not terribly hard to socket script your way through it.
> Ideally, code using the existing libraries would work with the server
> with only minor changes. I think it will be a big disadvantage if you
> have to have two separate code bases to work embedded versus
> client/server.
>
Agreed! Socket support would be something extra and optional- I'm just hoping
the door is left open for those that are up for writing the appropriate
wrappers.
Brian
--part1_30.2c2a65b3.2aa01c7f_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
<HTML><FONT FACE=arial,helvetica><BLOCKQUOTE CITE STYLE="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px" TYPE="CITE"><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2" STYLE="BACKGROUND-COLOR: #FFFFFF">
Yes, I agree that open protocols and published specifications are <BR>
great, but you'll want to have a good library on the client side of <BR>
the connection to make life bearable. Otherwise you are stuck parsing <BR>
every bit of data on your own. This is not HTTP and using something <BR>
like XML as the transfer protocol would be a mistake.</FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2" STYLE="BACKGROUND-COLOR: #FFFFFF"><BR>
</BLOCKQUOTE></FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2" STYLE="BACKGROUND-COLOR: #FFFFFF"><BR>
True- I have no desire at all to see XML here. However, if the bulk of communication uses SQL statements, we are not looking at a terribly complex transaction to query the database. Even HTTP protocol can get ugly, and its not terribly hard to socket scri
pt your way through it.<BR>
<BR>
<BLOCKQUOTE CITE STYLE="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px" TYPE="CITE"></FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2" STYLE="BACKGROUND-COLOR: #FFFFFF">Ideally, code using the ex
isting libraries would work with the server <BR>
with only minor changes. I think it will be a big disadvantage if you <BR>
have to have two separate code bases to work embedded versus <BR>
client/server.</FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2" STYLE="BACKGROUND-COLOR: #FFFFFF"><BR>
</BLOCKQUOTE></FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2" STYLE="BACKGROUND-COLOR: #FFFFFF"><BR>
Agreed! Socket support would be something extra and optional- I'm just hoping the door is left open for those that are up for writing the appropriate wrappers.<BR>
<BR>
Brian<BR>
</FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2" STYLE="BACKGROUND-COLOR: #FFFFFF"><BR>
<BR>
</FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2" STYLE="BACKGROUND-COLOR: #FFFFFF"></FONT></HTML>
--part1_30.2c2a65b3.2aa01c7f_boundary--
--part1_30.2c2a65b3.2aa01c7f_boundary
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
©2002 Yennie .AT. aol .D.O.T com |
