C Interfacing Options

[Bob Perez <bobp>]

Roger's already summarized the meeting between he, markm and 
myself and the various options we considered at that time for 
the level of interfacing to offer C programmers. I'd just like 
to add my thoughts with respect to each of these options:

1) Tranceiver level with BNF -- I wouldn't want this alone but 
I agree with Roger that since a lot of debugging will be done 
at this level it might have to be documented sufficiently to 
enable developers to track what's going on. But I'm not yet convinced.

2) Docs & Links libraries -- I'm not sure why roger believes 
this one will require the most work, but this is where I think 
the emphasis should be placed. A simple set of interfaces at 
the 88.1 level are -- I believe -- what most c programmers will 
expect and want. I think it's fine to let them use their existing 
libraries (hell, encourage them even) if they wish; if they're 
successful developers now, my guess is that they got that way 
at least in part by having pretty good libraries to begin with. 


3) I'm not sure there's much point to this one since as roger 
points out anyone attempting this approach will have to learn 
our X++-based tools (which means learning at least something 
about c++) and they wind up not much better off, complexity-wise, 
than if they'd just gone straight to c++. I'd prefer treating 
pointers to c++ classes as void *'s. In my mind, "reducing the 
mystery" doesn't follow perforce from giving struct access (I'm 
more interested in reducing the misery), and I worry about the 
consequences that will follow from the inevitable abuses.

4) This is the most interesting one to me, but from where I sit 
looks like it will require the most work. The idea is similar 
-- although not completely analogous -- to the Macintosh Package 
Manager, wherein various complex concepts are packaged into compact 
pieces of code which are then accessed via a simple, well-defined 
interface. The Macintosh List Manager, Standard File (the standard 
file-selection dialog you see on an Open command), and even the 
floating point libraries are accessed in this manner. If we could 
provide a set of interesting packages (e.g., text-editing, link 
& document creation) we not only simplify the whole process, 
we also creat some standards that can exist across platforms 
and help establish some Xanadu interface conventions. Obviously 
a considerable amount of thought will have to go into the interface 
designs.

5) I share roger's agnosticism, but agree that it probably wouldn't 
be too much work. One thing to consider is that most Mac C programmers 
don't even use stdio, and depend instead on the usual set of 
I/O facilities provided with most Mac C compilers (interfaces 
to the File Manager, Window Manager, etc.). On the other hand, 
virtually all C programmers in the PC market depend heavily on 
stdio as far as I can tell.

Summary: we should provide Docs & Link level libraries and documentation 
to C programmers, and perhaps some documentation of what's going 
on at the transceiver level. We should consider strongly the 
notion of specialized subsystems wherever they make the most 
sense.

-- bobp