🚀 go-pugleaf

In article <4035@osu-eddie.UUCP>, elwell%tut.cis.ohio-state.edu@osu-eddie.UUCP (Clayton Elwell) writes:
. We talked about this issue at the file representation session before
. Macworld Expo.  The problem is that there are text files, and there
. are other files (I, for example, routinely move TeX DVI files back and
. forth betweeen my Mac and our Pyramid 98x).  Unfortunately, it's not
. as simple as putting in a delimiter specification (see below for my
. solution (hack?)).
....
. Coming from the point of view of writing a server, I translate on the
. fly between native text format and Mac text format.  This does assume
. that you're not going to seek around in text files randomly (although
. in my case even this works, since my host system is UNIX).  If you're
. using it for archival purposes, a little utility to extract or replace
. a text file wouldn't be hard, and is usable in practice (it's what
. I've been doing for the last 6 months or so).  The combination of the
. file system identifier and file type should be enough information.

Once the data fork in AppleDouble is fully converted to the native
format, translating on the fly seems the only way to go.  The main
problem seems to be exactly the issue Clayton raises: which files
should be translated and which should not?

There are at least two solutions I can see:
    1.	The remote file system has an (administrator-editable) list 
	of file types that are translatable, presumably including TEXT
	and EPSF but not WDBN or 'DVI '; or
    2.	The server always does TEXT (for upward compatibility)
	and then there's another file bit somewhere added to
	Mac files indicating that this is CR-delimited text,
	thus allowing the server to know which ones are translated.

And I otherwise agree with Clayton, it's reasonable to expect the final
spec will include recommendations and examples that will nudge 
implementors in generally the same direction, just like the HIG, 
Inside Mac and the Tech Notes.