🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac
Article #18831

Re: Changes to the MacBinary standard

#18831
From: Brown
Date: Tue, 08 Sep 1987 13:16
46 lines
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!daveb
References: <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