rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/05/90)
Like, say you want a program to go away for a while and do some work.
Under X you lose the UI... and you can't even put up an "I'm busy" sign
because it won't get displayed until you return to the event loop.
Another over-generalization that seems typical for this list. "X" is a whole
lotta things these days. To claim that all instances of X applications are
single-threaded and strictly event-driven, in the canonical manner of Xt, is
rather silly. There are multiple researchers out there working with X on
the client side in a multi-threaded environment; there are even one or two
products that work this way. Whether a multi-threaded client environment is
better or worse than a single-threaded client with multi-threaded server is
rather debateable, I'd say. The design of Xt was a concious one, for its
portability across a wide range of systems. Clearly the model isn't adequate
for all applications; that's good, it was an engineering solution.jcb@frisbee.Sun.COM (Jim Becker) (01/09/90)
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
Like, say you want a program to go away for a while and do some work.
Under X you lose the UI... and you can't even put up an "I'm busy" sign
because it won't get displayed until you return to the event loop.
Another over-generalization that seems typical for this list.
I will try not to make the same mistake. These comments are focused on
_your_ comments regarding Xt.
"X" is a whole
lotta things these days. To claim that all instances of X applications are
single-threaded and strictly event-driven, in the canonical manner of Xt, is
rather silly. There are multiple researchers out there working with X on
the client side in a multi-threaded environment; there are even one or two
products that work this way. Whether a multi-threaded client environment is
better or worse than a single-threaded client with multi-threaded server is
rather debateable, I'd say.
I take this to be roughly an argument that a multi-threaded OS is
needed to support separate thread event dispatch using the Xt or other
similiar toolkit model.
What current OSes support this? Is this something that users can rely
on anytime in the future? Will all OSes to which X is ported allow
this model?
Given the basic design of the X event model there are a number of
problems that arise when creating more complex applications than those
more closely interface driven. These are starting to arise now that
developers are venturing into _real application land_.
The design of Xt was a concious one, for its
portability across a wide range of systems. Clearly the model isn't adequate
for all applications; that's good, it was an engineering solution.
~~~~~~~~~~~
Clearly the model is designed for simple applications, not those that
have vastly complex interfaces. The model breaks with more complex
interfaces and applications that do real work rather than heavy UI and
light functionality.
It is *not* good that Xt isn't adequate for all applications, simply
because it is being asserted as a _standard_ on which all toolkits are
to be based. If the initial foundation is inadequate then it should
not be deemed the standard on which all solutions are based.
By locking all users into a deficient standard prior to the
marketplace understanding the variables in the game, one has
effectivily crippled further progress in this area.
I have yet to meet someone that could understand programming Xt in a
single sitting; and there are pretty amazed reactions when people get
into understanding it. Those here that have attempted to use it have
been pretty smart, and it was no cakewalk to understand it for them.
My brain has done automatic garbage collection after reading the
various Xt texts, and I couldn't start writting a program using Xt.
Although I think that X it pretty good up through the Xlib layer,
seeing that Xt has become a stated underlying standard makes me have
to realize that those defining the standards haven't yet understood
the issues that will make X and Unix mainline consumer products. The
Xt solution increases complexity when it should be a high level
distilled usage of Xlib. Programmers out there don't want more
complexity, they need less. Why do you think that software never
catches up with hardware advances? Maybe the software isn't simple
enough to use... Unix will be a bane rather than a blessing if no one
decides that "engineering solutions" aren't wide market solutions, and
works on productizing Unix for real people rather than expert users.
Creating a barrier to learning and progress like the Xt gobbledygook
is bad enough in itself (sorry Ralph). But making this a standard that
all have to understand and suffer with simply limits the commercial
viablity of Unix/X in the face of OS/2 and PM. If we want X to win
then why is the door shut to creativity beyond the Xt class based
model?
Sorry to sound so negative, but I don't think that learning and
creating the interface should be 80% of the application development
time. I have created interfaces for large X applications in the past
and don't think Xt (or Interviews) based solutions will work. I would
really like to see an Xt based application with >100 windows, dialogs
and alerts. By that time those teams of programmers designing and
implementing widgets will have more than consumed the `peace dividend'
in time spent learning Xt and subclassing widgets!
The Sun solution of XView and Guide presents an example where the same
basic functionality of the interface mechanisms have been created sans
Xt. Last I checked InterViews didn't use Xt. Since there are
multiple ways to skin this cat, and you state that Xt isn't the final
solution, why is it a standard?
-Jim Becker
These thoughts are my own, and will probably get me into major trouble..
--
Jim Becker / jcb%frisbee@sun.com / Sun Microsystems
...these are my opinions, and even my id disagrees.. rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/11/90)
I take this to be roughly an argument that a multi-threaded OS is
needed to support separate thread event dispatch using the Xt or other
similiar toolkit model.
It's possible to use application-level threads and get somewhere. The main
problem with such an approach is system calls blocking all threads; you have
to understand application specifics to know how bad of a problem this is (but
it's definitely a problem for some applications).
What current OSes support this?
Mach, Sprite, Symbolics, TI Explorer, Cedar, V(?), probably others. It seems
like there is a relative abundance of application-level threads packages for C,
although few of them are widely/easily available I guess. Processes are now
fairly common in product Lisp systems. Several people have put threads into
C++.
Is this something that users can rely on anytime in the future?
If OSF has its way, Mach may be widespread eventually. :-)
There is a POSIX committee working hard on a standard Threads definition,
indications are that they are making considerable progress.
Clearly the model is designed for simple applications, not those that
have vastly complex interfaces.
I've seen a number of X products that are quite sophisticated. (I don't
know about "vastly complex", we don't encourage those. :-)
The model breaks with more complex
interfaces and applications that do real work rather than heavy UI and
light functionality.
The model breaks when there is significant "computation" in parallel with user
interaction, if that computation cannot easily be decomposed into Xt's notion
of "work procs". I agree completely. But, as I have argued in the (distant)
past, user interaction in sophisticated applications will very likely require
interaction with the "back end" data of the application, and can't always be
"downloaded" into a window server and run autonomously; multiple threads will
be needed in the client as well. I remember Mark Callow of SGI at a SIGGRAPH
panel a couple years ago admitting this turned out to be essentially the case
for several applications they had been building.
It is *not* good that Xt isn't adequate for all applications, simply
because it is being asserted as a _standard_ on which all toolkits are
to be based.
You have the emphasis in the wrong place. It is *a* standard; the X Consortium
does not view it as the only possible standard. I strongly disagree that one
should build the universal toolkit (whatever that is) or be damned; I'd much
rather take the 80% rule (and be damned :-). One of the common citations is
that Macs/PCs have a wealth of useful applications, yet they are based on
essentially the same model.
By locking all users into a deficient standard prior to the
marketplace understanding the variables in the game, one has
effectivily crippled further progress in this area.
When I count the number of new toolkits *still* being designed in the X
environment (whether Xt based or not), I find it hard to agree that progress
is being crippled. On the other hand, I've talked to a fair number of
real end-users (e.g. people from federal agencies), and their almost
universal cry is "give us something yesterday, I don't care what it is,
I trust you that it's good enough for what I need to build right now".
Standardization is an attempt to satisfy those kinds of needs, hopefully
without stiffling innovation. It's a tricky road to walk.
I have yet to meet someone that could understand programming Xt in a
single sitting; and there are pretty amazed reactions when people get
into understanding it.
Anecdotal evidence is hard to compare. I have an undergraduate (a freshman
as I recall) with no prior experience in windowing or graphics, just a little
bit of C programming. We gave him the task of rewriting bitmap(1) to be a
toolkit client, using the Athena Widgets. He read the documentation, asked
very few questions, and poof, he's got a reasonably good application up and
running (certainly much better than the current bitmap), including having
written his own widget.
Those here that have attempted to use it have
been pretty smart, and it was no cakewalk to understand it for them.
I agree it is difficult. I think a large part of it may be the documentation
(e.g. separating out cleanly what widget users need vs. what widget writers
need). I hope the Asente/Swick book nearing completion will help. And widget
set documentation is getting better, as people learn how to present the
information better.
But making this a standard that
all have to understand and suffer with simply limits the commercial
viablity of Unix/X in the face of OS/2 and PM.
Gee, I've read the PM documentation, and I can't say it's any better.
If we want X to win
then why is the door shut to creativity beyond the Xt class based
model?
Who in the world ever said it was shut? There is a wealth of creativity going
on. Look around; attend the X Conference. :-) But, there's no consensus on
any of it yet, that would enable standardization. I'm not really sure what
your complaint is. You seem to want the world's best toolkit, which doesn't
exist and probably won't in our lifetime, yet complain that people have agreed
to a common definition of something that does in fact enable a reasonable range
of applications to be built.
Since there are
multiple ways to skin this cat, and you state that Xt isn't the final
solution, why is it a standard?
Because multiple vendors rely on the Xt foundation, and desire to have a
common, vendor-neutral definition and evolution of that layer. If the
same were true of some other interface, the X Consortium would consider
standardization of it.rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/13/90)
[Jim Becker's message showed up on xpert first, here's what I sent there.]
It's a little strange that this conversation has been moved from
news-makers to xpert. (I prefer to be "one of the flamers" there,
rather than an apparent "authority figure" here. :-)
Since one of the goals
of the X Window System is to be widely transportable it seems that to
provide functionality that requires off-beat operating system features
would be shooting yourself in the foot.
My comments should be taken as forward-looking, not present-day exclusionary.
I come from a distributed systems background. I'm not particulary interested
in solving problems for X in isolation when they apply equally to a much
broader set of interfaces and applications. Multi-threading is just a case
in point; I'd rather not solve the "X problem" with multi-threading in the
server just because it's easier to do it there, when I see multi-threading in
a much more general context coming down the pike.
It would be unfortunate if these
efforts were tainted by a dependence upon functionality that is not
available to most users of computers.
I'm not really sure where you read this bias in my statements. I'm certainly
not advocating throwing out current mechanisms and requiring multi-threading
in the operating system in order to write Hello World. I am saying that for
those applications requiring the functionality, design should be done in the
context of what we know (or at least hope) is "just around the corner" for
the system layers beneath us.
I have to disagree in regard to `vastly complex' products.
I think you've read too much into what was intended as a joke.
The solution that you outline also sounds somewhat hairy. I
believe there are simpler ways to skin the cat, although they haven't
appeared yet.
I'm all for simpler solutions; I'd be glad to hear about them.
However I was under the impression that it was moving toward status of
an `exclusive' standard. I am not in the meetings where it is decided,
but the third hand info that floats by seemed to have the Xt toolkit
being put onto the exclusive standards list.
Third hand info is often confused. A great deal of debate has gone on
over NIST's proposed FIPS on X (government standardization), and over the
IEEE P1201 work at the toolkit level (formal standardization). Those are
both distinct from the standardization process in the X Consortium. The
X Consortium is not a ruling body for the government, IEEE, or ANSI, and
other politics come to bear in those domains. However, I am not aware of
any exclusionary wording in the current draft NIST and IEEE documents.
I believe the fact that there are so many efforts other than
Xt is testimony to support my view that Xt isn't the end of the story.
I have never said Xt is the end of the story; I'm not sure anyone ever has.
Ever try to teach your parents how to program a VCR?
Heck, I can't even program my VCR.
The beauty of the Mac is that they took all the complexity and
packaged it for the user into something understandable. The manual to
use the Mac is mighty thin, and comprehensive.
You have suddenly jumped from *writing* applications to *using* them.
A manual to *use* a well-designed X application set can be just as thin
and comprehensive. I would not call Mac programming documentation "thin".
(That doesn't mean I think a programming interface should be complex.)
Speaking of which, is there any weight given in the standards process
to complexity of use/comprehension, performance and commercial
viability?
Of course. The companies involved in a standardization process are seldom
in it just for a good time.
My involvement with the X C++ Consortium meeting at
Stanford seemed to be absent from these real issues.
This was also the kickoff meeting to C++ work, where it's very useful to
"blue sky" to get the feel for things. You don't know where good limits
make sense until you understand the space. It's rather simplistic to draw
too many conclusions from a single meeting like this.
What is going on in New Orleans this week? Thought there was
expectation of closure.
I'm way too busy to attend the P1201 meeting this week. (So why am I writing
this message?) If you know anything about the way formal standards bodies work,
and the short period of time that P1201 has existed, you can answer this
question yourself.