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

[Sven M. H. <pe...@so...>]

-----Ursprüngliche Nachricht-----
Von: Uwe Hermann <uh...@bi...>
An: hts...@li...
<hts...@li...>
Datum: Sonntag, 9. Januar 2000 20:05
Betreff: Re: [htsserver-devel] D-0002.txt: Holsham Traders Server-Replies


>> 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.


No. Client developers should be given a clear view over which responses to
expect. They must be specified by a set standard and not in the source.
Looking at the large number of RFCs concerning the FTP protocol, we see that
yes, there will probably be several changes in the set of responses and
their codes, but any such changes must be clearly announced in a new
revision of the protocol standard (so client developers can state which
standard their client complies with). And the place for new revisions of
protocol standards are definately the concepts.

hm... here another thing comes to mind... A concept which is outdated by a
new revision should not go to /dev/null right away. People should be able to
read it as a matter of information. My suggestion: Change D-0001 so the
naming specification for concept files is now

    (D|C)-xxx-yy.txt

where 'xxx' is the concept ID and 'yy' is the revision number. Note:
changing the concept ID to a 3-digit number keeps the name fitting in MS-DOS
style 8.3 notation.

>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?


Are we talking some kind of data transmission? What kind of data will we be
sending that uses so much space?
I don't think we should be passing stuff directly to the trade engine
because then we have some sort of sub-protocol which is kind of ugly IMHO.
Rather - if it is necessary to send large sums of data - the protocol should
specify some sort of simple command which causes the server to await the
data whose length will be given as an argument of the initial command.

>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.


Server-side... hm... *headscratch*
I don't think the server will need to send large lists of goods or whatever
by itself. that will probably only be caused by some sort of client request
for a complete list or something. But in any case I suggest using a
multi-line reply. That reminds me, I'd make multi-line repies have the form:

xxx-blahblah
otherblahblah
  moreblahblah
 xxx blahblah that looks (almost) like the end line
xxx end of blahblah

that's kind of like the way FTP does it. However, we should forbid nested
replies (that's specified in FTP actually) because we won't need them and
their an unecessary complication.

so the client will act like this:

] if I get a reply with a hyphen (-) immediately following the reply code,
    interpret the reply and parse the following lines accordingly
] once I hit a line which starts with the same three-digit reply code as
    the initial one followed by a space, treat this as the end of the reply.
] when parsing the reply line, strip any leading space

This way we can send almost anything in a multi-line reply except stuff
starting with spaces and I don't think we'll need that.


bye,
Sven