UI: Qs to get the ball rolling

[Francois-Rene Rideau]

> I've a question about this proposed design:
> 
> 	How does it scale?
> 
> When you've a large system, with pieces supplied by several vendors,
> and part of it isn't working, how do you isolate the problem?
   If parts can eventually be proven correct, vendors of buggy parts will
be the shame of computer industry. Then, "bugs" will exist only as one
thing: people writing programs without understanding what these program
should actually do. Thanks to active annotations, the system will also be
its own interactive debugger if needed.


> More generally: the less code does, the faster it runs.  However, you
> still need to design what it does do.
   That's exactly what we've been saying: having small, generic objects,
that each do very few, yet powerful, and combine them, instead of having
a few huge centralized bloated servers that do everything, are unpowerful,
unmaintainable, unoptimizable.


> So far, I've seen "it does objects", (ok, I oversimplify a bit).
   Unhappily, we haven't been much into details yet. I haven't had time
to settle this, because there's so much to do about all those projects.
I'm sure if you and other Tunespeople would manage various subprojects,
each maintainer could focus on details of his particular project, and work
would be greatly accelerated.
   In my last UI post, I tried to develop more specific subjects, and in the
HLL WWW page, I am being more and more specific. Now that we seem to agree
on general design (well, the LLL seem not to have advanced much these times),
work IS going down to details...


> I'd feel a lot happier about this system if had something catchy about
> it to catch interest (e.g. it's good for fast graphics games) up
> front, and maybe something a bit more serious in the wings for later
> (e.g. a WWW writing and scripting system).  [P.S. Anyone know how to
> make a massive "pick items from list box" under WWW that can be
> re-used in a number of different contexts? ?]
   I really all these are doable. Tunes should eventually support its own
WWW replacement/enhancement (perhaps Xanadu ?), which consistent caching.
Actually, this will be a trivial application of publishing consistent
documents in a true distributed system.