Re: [htsserver-devel] D-0002.txt: Holsham Traders Server-Replies

[Uwe H. <uh...@bi...>]

On Sat, Jan 08, 2000 at 03:33:56PM +0100, Sven M. Hallberg wrote:
> > > Again, my suggestion would be to use some ftp/smtp style protocol.
> > 
> > That's what I intend to do :)
> 
> Good. Just to clarify, then we'll have:
> 
> - _three_ digits.

Yep.

<THINKING>hmm, must try to make myself clearer</THINKING> :)

> - the following basic groups of replies, identified by the first digit:
>   (quoted from the SMTP protocol specification RFC821)
> 	1yz   Positive Preliminary reply
> 	2yz   Positive Completion reply
> 	3yz   Positive Intermediate reply
> 	4yz   Transient Negative Completion reply
> 	5yz   Permanent Negative Completion reply
>   see the RFC for a detailed description of each group.

> In addition however we should adopt a group with first digit 0 to designate
> replies that aren't really replies to anything, just information sent by the
> server as a result of changing conditions in the universe.

ACK.
 
> I'm not sure whether we should take the 2nd. digit from SMTP too, but I have
> looked them over and I think they fit quite well (better than the FTP ones).
> Of course we might modify them to fit our needs (especially x5z - mail
> system).
> 
> In general, again, I suggest sticking as close to the existing standards as
> possible, because they have proven to work well.

Basically yes. But we shouldn't stick to it just because it worked well
for FTP/SMTP, but because we think it will work well for htsprotocol,
too.
 
> I further suggest a second or third digit of 0 to mean 'unspecified', so the
> server is not forced to support every specified reply right away and the work
> imposed on client developers to understand this is minimal.

ACK. 200 would then be a general "OK" reply.

> Without the need to implement everything right away we should try to specify
> all replies we want in the concept file as soon as possible.

Nope. The Concept file just describes how things work.
The specific 3-digit-numbers and the text should be in the source-code.


I attached a revised version of D-0002.txt. Comments welcome.


We still need to think of a way to transfer more than 256 bytes.
Maybe it's better to have protocol-commands like 'buy', 'sell',
'drive' etc., instead of using 'transfer 4000' and passing the 4000
bytes to the trade-engine? Opinions?

Maybe the server should send 
"000 Get list of goods from next data sent to you."
and then send a 4000 bytes long data-stream with all the names of the
goods.


Uwe.
-- 
Uwe Hermann <uh...@bi...>
http://www.bingo-ev.de/~uh1763/index.html
-----------------------------------------
:wq