Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!amdcad!sun!imagen!atari!portal!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.arch
Subject: Re: Endian wars
Message-ID: <989@auspex.UUCP>
Date: 10 Feb 89 09:20:51 GMT
References: <6133@columbia.edu> <186@aucsv.UUCP> <21557@ames.arc.nasa.gov> <9468@cit-vax.Caltech.Edu> <21609@ames.arc.nasa.gov>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 33

>I remember seeing a definition of XDR a couple of years ago - but in the 
>context of RPC.

XDR's spec tends to be bundled with RPC's spec, but XDR is a data
representation format that can be used on a spinning oxide coated
platter, or a strip of oxide-coated plastic, just as it can be used on a
wire.  The UNIX XDR from Sun implementation can stuff XDR'ed data into
memory or pick it up from memory, or write it to a standard I/O stream
or read it from a standard I/O stream.  You can, in fact, define your
own XDR stream implementation types, if the canned ones that come with
the user-mode RPC library (standard I/O, memory, and "record stream" -
can be used over a TCP connection, or into and out of a file, or....)
won't do what you want. 

>Is there an XDR FILE format definition?

Well, there are the formats generated and read by the standard I/O and
"record stream" XDR stream types.  I suspect the standard I/O format
consists of a sequence of the encoded objects, shoved to the file as
bytes in the format specified by the XDR spec.  The "record stream"
format is probably similar, but with some form of "record marks" in the
stream (the documentation claims the record marking mechanism is
described in "Advanced Topics", but it's not described there in the
ONC/NFS Protocol Specifications and Services Manual).

>NFS certainly doesn't translate to/from it. 

No, and I doubt it could do so, given that many file formats are not
self-describing.  If you want to maintain a file over NFS that's
readable and writable by clients with different "native" data
representations, you're probably best off using XDR in some form to
write the data out (either XDR into memory and write/read and XDR from
memory, or use XDR over standard I/O, or XDR over "record stream", or...).