Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!palomar.UUCP!joel%beowulf
From: joel%beowulf@palomar.UUCP
Newsgroups: comp.protocols.appletalk
Subject: Remote file representation
Message-ID: <8708250004.AA03964@beowulf.UCSD.EDU>
Date: Mon, 24-Aug-87 20:04:31 EDT
Article-I.D.: beowulf.8708250004.AA03964
Posted: Mon Aug 24 20:04:31 1987
Date-Received: Wed, 26-Aug-87 00:36:02 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 82

First, I'd like to thank Apple for sharing this before it's set
in stone.  There are many Mac programmers who are on USENET, 
(and also Delphi and Bix, which receive edited copies of USENET news)
who can participate.

The spec seems well thought-out, but I have a few suggestions:

1. Home File System should include:
	'vms ' or $766D7320
	'os2 ' or $6F734220
   I'm not sure if 'unix' should be treated as a monolithic
   whole, as the syntax of file names, at least, differs significantly
   from System V (14 chars max) to BSD.

2. The AppleDouble format does not address one important issue.
   The data fork of a Macintosh file is not normally readable
   by another file system.  To contrast it with three with
   which I am familiar:
	*) Mac: CR at end of each record
	A) UNIX: LF at end of each record
	B) MS-DOS: CR-LF at end of each record
	C) VMS: preceeded by a binary length
   If the data fork is to be readable, then it must be translated
   into the native format, and its original format saved.

   I think there needs to be a line-translation entry to indicate
   the original line delimiter so it can be restored from the
   native format
	Record Delim 9  1 or more delimiter characters
   For example, a Mac file stored on MS-DOS would be stored with CR-LF
   delimiters but with Record Delim = $0D.  (on VMS, you could use
   RAT=CR, which would be an exact copy of the Mac data fork).

   The AFP or some other protocol also needs either record-
   at-a-time i/o or a "What is this file's delimiter" query, so
   that a Mac program can read a file directly from a UNIX
   server (in LF-delimited form) and vice versa.

3. The use of the icon ought to be better defined, or this will
   vary all over the place.  For example, the spec ought to say
   something like:
	Applications normally include their icons, but documents
	do not.
   (or maybe all always include their icon)

4. Again, their ought to be file naming guidelines for mapping
   (recommendations for consistency, not absolute rules) so that 
   there is similarity between various systems.  For example,
     A) Case is stripped on systems that don't support case, so
	Foo.C becomes FOO.C
     B)	Spaces are mapped to "_" if available, otherwise to
	another available non-alphanumeric special character.
     C)	Standard mappings for Macintosh extended characters.
	For example, all accented letters are stripped to their
	IUMagString equivalents,
		`e becomes e
		c, becomes c
	etc.  Characters that have no equivalent are removed
	((R), TM, (C), etc.) since they are likely to be noise
	characters.

5. Presumably if a new file is being created in this directory
   and it truncates to an existing AppleSingle or AppleDouble
   file, the program will check for the actual name and, if
   different, choose a new truncated name to save the file.

   For example,

	'AntiDisestablish Text' and 'AntiDisestablish Text 2'
   might be stored as
	ANTIDIST. and ANTIDIS2.
   on an MS-DOS system.

This is obviously an area where a standard is sorely needed,
and as an A/UX user, I hope A/UX 1.0 implements the final 
AppleDouble proposal.

	Joel West		
	Palomar Software, Inc., POB 2635, Vista, CA  92083
	joel%palomar.uucp@beowulf.ucsd.edu
	ihnp4!crash!palomar!joel	joel@palomar.cts.com
	AppleLink: D0619			MCI: Palomar