Article View: comp.sys.mac
Article #18831Re: Changes to the MacBinary standard
From: Brown
Date: Tue, 08 Sep 1987 13:16
Date: Tue, 08 Sep 1987 13:16
46 lines
2926 bytes
2926 bytes
In article <16387@teknowledge-vaxc.ARPA> dplatt@teknowledge-vaxc.ARPA (Dave Platt) writes:
>The following text describes some proposed enhancements to the
>MacBinary file-transmission standard; ...
>The format of the header for MacBinary II is as follows:
> Offset 000-Byte, old version number, must be kept at zero for compatibility
>[discussion of how to infer version with 0 version number]
You perhaps misunderstand the meaning/use of a version number. Back
in the days of the ARPANET and the Project MAC, they were invented to
provide a transparent means of allowing programs to evolve.
If there is only one version number (the common case), it is
incremented to indicate to an old program that this is a new-format
file (or packet!) and that it needs to execute its "exceptional case"
code. Often this meant is was to complain to a human and, in the case
of translators, refrain from translating things into broken bits. If
the version number is not incremented, the program can process the
file/packet, ***ignoring** present-but-unimplemented fields and still
produce a valid packet/file.
If there is a two-part version number (rare) or there is a
negotiation procedure (common on ARPANET/in Kermit) the program can
use the additional information to read and interpret
present-but-unimplemented fields, since it has just been "told" which
ones are in use.
Please do not publish a standard which does not have a mechanism for
evolution and change. The world will insist on changing...
In the case of MacBinary, you may want to release a standard and a
suite of programs which:
1) ignore present-but-unimplemented fields
2) provides a few for extension
3) has and uses version number of 0, but...
4) defines version 1 and can read all version 1 files
5) does not send version 1 until 1 january 19XX, then switches
automagically.
Please feel free to contact me by mail, I will be glad to lend a
hand (outside of working hours (:-})) at helping you improve the
standard without breaking existing software.
--dave (notice the quote below) c-b
--
David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb
Geac Computers International Inc., | Computer Science loses its
350 Steelcase Road,Markham, Ontario, | memory (if not its mind)
CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
Technical Details
Message-ID:
<1332@geac.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!yetti!geac!davebReferences:
<16387@teknowledge-vaxc.ARPA>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!mnetor!yetti!geac!daveb From: daveb@geac.UUCP (Brown) Newsgroups: comp.sys.mac Subject: Re: Changes to the MacBinary standard Message-ID: <1332@geac.UUCP> Date: Tue, 8-Sep-87 09:16:34 EDT Article-I.D.: geac.1332 Posted: Tue Sep 8 09:16:34 1987 Date-Received: Wed, 9-Sep-87 01:28:25 EDT References: <16387@teknowledge-vaxc.ARPA> Reply-To: daveb@geac.UUCP (Dave Collier-Brown) Organization: The little blue rock next to that twinkly star. Lines: 46