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