[Fwd: Re: [sac-dev] byte order and swapping]

[Brian Savage]

I forgot to post to the list, but instead sent just to George.
This is George's response to me.

Hi Brian -

On Monday, November 21, 2005, at 06:22 PM, Brian Savage wrote:

> It sounds like whatever we decide, the file formats (SAC and SGF) need 
> to be documented.

Amen.  But where?  There really isn't any "formal" SAC documentation
any more, just broken links hanging around on the web and outdated
pieces of paper that I have from old SAC manuals.  It would be valuable
to have that roff source code (or whatever word processor LLNL used)
available somewhere to build modern documentation from.

>
> Concerning SGF.  If it has always written the files in the same way, 
> why change it, make it the standard and document it.

I'm not sure whether SAC always wrote files that way, but for as long
as I've worked on it it has.  Still, that may not be the way that
others like Arthur have written SGF files!  You are implicitly
abandoning that community (which is probably small).

>
> Concerning SAC.  If we decide all SAC files should be in big endian 
> format (or even little) I am certain there will be an outcry from the 
> community who uses Sac for processing and as a data file format.

I'm not as certain as you are about this.  MacSAC users haven't
complained about initially having to use sactosac with whatever
heritage their data is.

> If we specify an endianness, we are introducing more bugs on linux 
> machines as they will not be able to read current sac files which are 
> written in little endian.

Previous comments apply.  It is simple to modify sactosac to always
write big-endian or little-endian.  Besides, SAC isn't an archival
format, but a processing format.  One doesn't need to change anything
until it is used.

>
> Brian
>

PS if you meant to post your response to the list, only I got it.  You
can post this and get both if you want.


      George Helffrich