AmiagBinary
2 messages in this thread
I have finally forced myself to sit down and respond to the AmigaBinary
suggestions. Some comments:
1) It is useful to leave 128 byte block alignment in the standard. The reason
is to simplify implementation. It is quite simple to build a state machine
that the xmodem sender/receiver makes requests of. Alignment makes it much
easier to construct/break-down the transmission on-the-fly. This is also true
because several files must be opened/closed during the total process. File
opening/closing is slow compared to other operations and it is most desirable
to do this at "packet" boundaries.
2) I am concerned about the provisions for SQ/USQ/ARC in the protocol. I
think AmigaBinary should define a minimum implementation that everyone should
implement. As suggested, I think we will see terminal programs with several
different levels of implementation. The net result will be confusion to the
"non-expert". This objection may not be valid if "public-domain"
implementations of these routines are available to everyone.
3) An observation: the Amiga community assumes much more expertise on the
users part than the Mac community when using a modem. In particular, file
compression/packing has never really caught on in the Mac community (note: I
am not suggesting that it shouldn't be done). It is just important for us
"experts" to appreciate the problems of "non-experts" and design a process
that simplifies things as much as possible. Bill Bond
Bill,
I don't see that the 128 byte alignment makes any difference in implementing
the transfer. A sender builds a 128 byte header, then sends the whole thing to
the protocol stream; a receiver, when it needs another header, requests 128
bytes from the protocol stream. Those primitives will be needed for the actual
file sends and receives; doing the header with them makes no difference.
I agree that there's a slight advantage to doing file opens/closes at packet
boundaries, but it's slight. With a system of input and output streams, the
AmigaBinary formatter shouldn't even be aware of packet boundaries. Anyway,
128 is only a boundary for XMODEM. A, B, YMODEM and Kermit all use different
packet sizes.
AmigaBinary does define a minimum implementation, which does not include
SQ/USQ/ARC handling. Also note that I hope to have a PD implementation of a
full AmigaBinary packer/unpacker, relatively soon (I will write it if nobody
else does).
One purpose of AmigaBinary is to make things simple for the non-expert.
Given a full AmigaBinary implementation in his terminal program, the non-expert
needs only to get the host to start sending, then tell his terminal program to
receive a file. The program takes it from there.
The provisions for squeezing/etc, and also for multiple files, are defined to
give a standard to their implementation instead of having people come up with
their own tangential additions to the format. I'm not really expecting first
implementations to handle those things, but some day people will be doing them,
and they'll have a common standard instead of doing it their own way — I
hope…
I hope you'll help. – Bela
PS: *$&#! I meant to upload this reply a while ago, but forgot to (along with
the rest of this file). I will be putting up the next revision of the spec
tonight or tomorrow, but I may extend the change deadline another week,
depending on what happens.