Forum unknown
· Telecommunications
#AmigaBinary
11 messages in this thread
I saw your message about file transfers. Take a look at the MacBinary standard
which is in dl3. Below is my proposal for modifications to it so that it would
work for the Amiga. I have maintained the same offsets. Note that the File.info
would be moved and rebuilt if available. This would allow "non-expert" users to
move files.
Offset Length Description
—————————–
0 1 Zero
1 1 Filename Length
2 63 Filename
65 8 Undefined
73 1 Lower 8 bits of Protection Mask
74 1 Zero
75 7 Undefined
82 1 Zero
83 4 File Length
87 4 File.info Length
91 35 Undefined
126 2 Computer Type – $0200
Couple of notes:
1) The filename field is larger than needed (30)
2) File Comment is not moved
3) The file date is not included (because I currently don't
understand how to obtain/set it)
I have a C implementation of MacBinary that I am going to try to convert. If
you are interested, we could discuss this more by voice. Bill Bond
Bill, I assume you've read the ABTF doc. How about the CRC integrity check I
proposed? It does away with the user having to determine whether he would want
AmigaBinary "turned on or off." This seems to me to be the weakest part of the
MacBinary standard, especially for novices.
You should also probably reserve a space for the time/date, even if the method
for getting/setting it isn't feasible yet. This would save hacker-supplied
kludges at a later date.
Russ, the idea you put forth about the integrity check is indeed a good one.
The best part about it is that it doesn't really require any modification to
the existing spec (if I read it right). I also agree with date/time being a
necessity, and to reserve space at this time would be good. I also think that a
decision should be made early as to the format of the date/time fields so that
this extension would also be terminal dependent, to be implemented as the term
author sees fit.
Has there been any further discussion concerning the format of the header to
indicate that it is a multiple file transfer?
I was just commenting on the outline that Bill put up. A final decision hasn't
been reached yet re: ABTF (it's still being talked up) but I imagine that the
block transfer flag will stay. One problem which is being worked on is what
should happen when a BBS tries to send multiple files to a terminal program
which doesn't support the batch transfer. Since the proposed format suggests
that a terminal program "ignore all data that it doesn't know what to do with",
(since extensions which extend the length of the sent file are
possible/probable) some method should be used to alert the BBS that no more
files are wanted. Unfortunately, this falls outside the realm of the format,
which is supposed to be protocol independant (i.e. how you signal to the BBS to
stop sending would depend on the protocol.)
[ Russ ]
Russ, I was under the impression that the host end would not even realize
that there were multiple files being transferred. In order to make it
protocol independent, the host end must recieve a single transfer consisting
of one or more files strung together. To do multiple transfers to a host
consisting of many files that are to be stored independently would require
knowledge on the host end or a simulation between transfers of all the
necessary comands to set up each file.
In the case of two terminals supporting Amigabinary, the problem of stopping
in mid stream could be tricky, depending on the presence or absemce of a
total crc/checksum for the entire block that could be part of a protocol
definiton.
Russ, I was under the impression that the host end would not even realize
that there were multiple files being transferred. In order to make it
protocol independent, the host end must recieve a single transfer consisting
of one or more files strung together. To do multiple transfers to a host
consisting of many files that are to be stored independently would require
knowledge on the host end or a simulation between transfers of all the
necessary comands to set up each file.
In the case of two terminals supporting Amigabinary, the problem of stopping
in mid stream could be tricky, depending on the presence or absemce of a
total crc/checksum for the entire block that could be part of a protocol
definiton.
I was just commenting on the outline that Bill put up. A final decision hasn't
been reached yet re: ABTF (it's still being talked up) but I imagine that the
block transfer flag will stay. One problem which is being worked on is what
should happen when a BBS tries to send multiple files to a terminal program
which doesn't support the batch transfer. Since the proposed format suggests
that a terminal program "ignore all data that it doesn't know what to do with",
(since extensions which extend the length of the sent file are
possible/probable) some method should be used to alert the BBS that no more
files are wanted. Unfortunately, this falls outside the realm of the format,
which is supposed to be protocol independant (i.e. how you signal to the BBS to
stop sending would depend on the protocol.)
I was just commenting on the outline that Bill put up. A final decision hasn't
been reached yet re: ABTF (it's still being talked up) but I imagine that the
block transfer flag will stay. One problem which is being worked on is what
should happen when a BBS tries to send multiple files to a terminal program
which doesn't support the batch transfer. Since the proposed format suggests
that a terminal program "ignore all data that it doesn't know what to do with",
(since extensions which extend the length of the sent file are
possible/probable) some method should be used to alert the BBS that no more
files are wanted. Unfortunately, this falls outside the realm of the format,
which is supposed to be protocol independant (i.e. how you signal to the BBS to
stop sending would depend on the protocol.)
I was just commenting on the outline that Bill put up. A final decision hasn't
been reached yet re: ABTF (it's still being talked up) but I imagine that the
block transfer flag will stay. One problem which is being worked on is what
should happen when a BBS tries to send multiple files to a terminal program
which doesn't support the batch transfer. Since the proposed format suggests
that a terminal program "ignore all data that it doesn't know what to do with",
(since extensions which extend the length of the sent file are
possible/probable) some method should be used to alert the BBS that no more
files are wanted. Unfortunately, this falls outside the realm of the format,
which is supposed to be protocol independant (i.e. how you signal to the BBS to
stop sending would depend on the protocol.)
[ Russ ]
Russ, the idea you put forth about the integrity check is indeed a good one.
The best part about it is that it doesn't really require any modification to
the existing spec (if I read it right). I also agree with date/time being a
necessity, and to reserve space at this time would be good. I also think that a
decision should be made early as to the format of the date/time fields so that
this extension would also be terminal dependent, to be implemented as the term
author sees fit.
Has there been any further discussion concerning the format of the header to
indicate that it is a multiple file transfer?
Bill, I assume you've read the ABTF doc. How about the CRC integrity check I
proposed? It does away with the user having to determine whether he would want
AmigaBinary "turned on or off." This seems to me to be the weakest part of the
MacBinary standard, especially for novices.
You should also probably reserve a space for the time/date, even if the method
for getting/setting it isn't feasible yet. This would save hacker-supplied
kludges at a later date.