What should go in standards

[Eric Roskos]

In article <19658 at bu-cs.BU.EDU>, bzs at bu-cs.BU.EDU (Barry Shein) writes:
> 
> (Responding to a note from Eric Roskos)
> 
> Actually, I disagree.

Well, generally I agree with your comments, so it may be that I have not
explained my original comments very clearly.

> 
> >In terms of the "modern needs" above, how much of that is *really*
> >necessary?  For example, remote file systems [should be transparent].
> 
> Unfortunately in practice there are these "little" nits (eg.
> statelessness vs statefulness, perhaps new error codes or mount
> options), I suppose one could come up with an abstract super-set, so
> let's leave all that for a moment.

I'll agree with that in part.  I would be really reluctant to see new
error codes that described non-routine, network-specific errors as
other than a generic "I/O Error" simply because the number of error
codes of that class which other device types could contribute is so large.
As I stated before, I do agree that things like new mount options could
be necessary.

> The real issue is from the vendor's point of view. If I want to 
> support a remote file system
> I have to pick one, the fact that they're all roughly alike and don't
> interoperate is a problem, not a solution.

I'll agree with this too, but as I said, this should be a separate
standard.  What the current committees are mostly addressing now are
things that the user sees.  How one machine communicates filesystem
requests to another machine is a protocol issue, and should be
addressed in a protocol standard.

> Windowing I think is an easy issue to respond to. It's critical.

I avoided this issue because it is a hard one, but I will expand on
it here.  This is more of an architectural issue, though, and I am
reluctant to discuss it in unix.wizards.  Anyway:

> Again, you're a vendor, you're planning an interactive software
> product which could use windows effectively. What do you choose to
> code? To
> improve marketability you want to choose something standard. In fact,
> this particular issue is so bad that the truism going around
> is one reason you don't see
> products like [Microsoft] Excel on Unix workstations is simply that they're
> waiting until Unix presents a standard window interface so they can
> port their code once and just sell it, not port it over and over again ...

Well, I worked on Excel for a year, and although there's really nothing
I can say about that, as far as portability issues are concerned there
are a lot more issues confronting microcomputer applications developers
than that.  In general, the state of the art is far from the state of
the practice as far as microcomputer developers are concerned.

The problem with windowing, the problem I didn't address before, is that
it is still too much an open field in terms of basic architectural concepts.
By way of analogy, particularly on microcomputers, windowing is at the
level of development that programming was at when everyone programmed in
assembly language.  That is to say, each windowing implementation provides
a very wide variety of primitives simply because people haven't yet decided
what a minimal set of primitives should be.

That's what led me to say "I don't think one should standardize too early."
In a sense it's true that

> a standard just says you should support
> this to claim you are standard, not that you don't have anything else,
> so it shouldn't limit anyone other than the time and trouble to get
> the standard working correctly (if it's truly a successful standard
> the effort should be worthwhile.)

but also it's true that standards (a) tend to discourage improvements
since people are all trying to be standards-compliant, (b) tend to
constrain technology, especially if they are not abstract enough, since
often by the time the standard comes out, the technology on which it
was based is obsolete, and (c) tend to bias the way people think.

On this machine I am using now (a Sun), we have two different windowing
environments I have to use to get my work done, and it does irritate me.
But I wouldn't want to see either one of them become a standard at this
point.  One of them doesn't have the support for a certain standard
displayed-text representation language which one application I use needs;
the other one is too slow and has a clumsy process model.  This is not
to say that a standard couldn't be created that has the best of both,
rather that the way standards get created, it is highly unlikely it would,
at this point, partly because the standards-makers tend to be partially
unaware of how much context they carry with them into their thinking
on how a system should work.

I agree with you that windowing is essential; but I don't think it's time
to standardize it yet.

> What's the problem anyhow? TCP/IP is a de facto standard, almost all
> vendors offer it as a primary product anyhow, it's available, it works
> etc.

You are outside my area of expertise now, but I seem to recall reading
a paper just about a week ago that indicated that TCP/IP was being
phased out in some critical areas because there is another standard that
is more widely used.  I'll have to leave that for somebody else.

Underlying my argument, though, is a more general concept, having to do
with changes I see in Unix recently.  It perplexes me when I read
comp.arch to see that the same people who are strong advocates of RISC
architectures seem to be the strong advocates of complex Unix-like
architectures.  I remember reading in one of Dennis Ritchie's speeches
in response to some award he was being given that he said something like
"I must admit feeling uncertain about this award, since I have had nothing
to do with what's considered mainstream Unix for many years."  There's a
fundamental principle to that.  The ideas Ritchie and Thompson set forth
in their original papers on Unix, the ones explaining its philosophy,
seem to have disappeared in a lot of areas; first in Berkeley Unix,
later in other forms of it.  Specifically, the "kernel as a soapbox"
idea, or, the idea behind that one.  It's easy to design a system that
does everything anybody wants, although getting it to work may be a problem,
and keeping it working an even bigger problem; but it's hard to design
a system that does useful things well, and succeeds in providing something
better than what people first wanted, the sort of thing they end up wanting
in the end, but without carrying along all the intermediate features
indefinitely in the process.  That was what I was referring to, a sort
of architectural discipline.

----
Microsoft Excel is a trademark of the Microsoft Corporation.
Unix is a trademark of AT&T.
-- 
Eric Roskos, IDA (...dgis!csed-1!roskos or csed-1!roskos at HC.DSPO.GOV)
	"Only through time time is conquered."  -- Burnt Norton