Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.software-eng
Subject: Re: How Do Interface Description Languages Work?
Message-ID: <8092@goofy.megatest.UUCP>
Date: 17 Sep 89 03:07:59 GMT
References: <12697@joshua.athertn.Atherton.COM>
Organization: Megatest Corporation, San Jose, Ca
Lines: 38


From article <12697@joshua.athertn.Atherton.COM>, by joshua@athertn.Atherton.COM (Flame Bait):


> If you want a better IDL, I'd look at Sun's XDR system. 


Then, not finding it there, look elsewhere.


> [It] was designed from the begining to be a general purpose data language
> (ie. to be used for more than just remote procedure calls).  This difference
> in design philosophy shows.  Also, XDR can support any data type used by
> C ...

Huh?

It can't even handle directed acyclic graphs, even with all the pointers
nicely pointing to the "tops" of the structures. It turns them into
trees. On a cyclic graph, it will get into a loop and spew data until
something bursts.

There are other problems with XDR. It uses binary format for integers,
floating point, etc.. The formats are exactly the ones used internally in
Sun workstations. (Amazing coincidence that.) So if you use only
Sun workstation, there is no data-conversion necessary. If you don't, get
ready to start programming. You may have to write conversion routines for
going between IEEE floating-point (XDR standard) and whatever else you have:
IBM or MIT or some other floating-point format. I don't think those routines
are provided.

So, why not just do what XDR should have done... use text to represent
integers and reals? Everybody has printf and scanf. Good idea, but there
is no provision for automatic conversion of text from ascii (the unspoken
XDR standard) to ebcdic and back to ascii.

Perhaps the worst thing about XDR is that if you use it, you may be
tempted to use RPC.