Re: The spec evolves...

marca@ncsa.uiuc.edu (Marc Andreessen)
Date: Mon, 7 Dec 92 01:37:12 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-id: <9212070937.AA06202@wintermute.ncsa.uiuc.edu>
To: Dan Connolly <connolly@pixel.convex.com>
Cc: Guido.van.Rossum@cwi.nl, marca@ncsa.uiuc.edu (Marc Andreessen),
        www-talk@nxoc01.cern.ch
Subject: Re: The spec evolves... 
In-reply-to: <9212070617.AA12781@pixel.convex.com>
References: <9212070617.AA12781@pixel.convex.com>
	<9212070641.AA05810@wintermute.ncsa.uiuc.edu>

Dan Connolly writes:
> Good point. I didn't mean that we should make the physical distance
> to the link destination known to the user. But I think users would
> benefit from knowledge about the logical distance -- i.e. is
> it part of the same node, part of the same document, or in some
> other work completely? Is it more specific or more general
> than this node?

Maybe a compromise: if linking to a point in the same document, color
the anchor orange; if linking to a point on the same server, color it
red; if linking to somewhere else entirely, color it violet.  Or a
variation on that theme.  This wouldn't require changing HTML and
wouldn't be too obtrusive to those of us who like transparency.

> [Discussion on what to do with links to GIF files.]  So perhaps it's
> not the HTML data format that's doomed, but the <A> element. I guess
> the lesson is: you can't teach an old element new tricks.

I think looking at the file extension will solve 95% of the cases
(that's what extensions are for, after all).  The remaining 5% could
be addressed by Content-Type.  The browsers should be brought up to
speed.  That's one approach -- just getting multimedia out the door
and merged into the current HTML spec calls for the simplest solution
possible, at the moment.

> Counterpoint: when the design is complete, performance-critical code
> can always be written in C and added as a module. In the mean time,
> the benefits of rapid-prototyping outweigh the performance
> penalties.

Yeah but, yeah but, once something is written with rapid prototyping
in mind and turns out to work, odds are it's going to be *the*
implementation, as its implementor goes on to bigger and better
things.

> I don't mean to base the W3 architecture on Python -- only some
> implementations.

Right.  Those implementations then will be (no offense to the Python
folks intended, but here it comes...) chained to Python, which will
put an instant damper on their general usefulness -- they're never
gonna be merged into anything else and thus made more useful, unless
that something else uses Python also, which (as is the case with all
the rest of these systems) is just plain doubtful.

> Viola and tk/tcl: These try to do what's already been done in
> the Xaw and Motif toolkits, and they don't do it as well. (I suppose
> this is your point...)

Yup.

> Midas: This is a specially designed language highly suited to it's
> purpose. Only the highest level of code in the Midaswww browser is
> written in Midas. All the rest is reusable. Tony did a heck of a
> job.

I agree with the latter point, but not the former.  There's very
little reusable code in Midaswww.  I spent quite a bit of time trying
to rip the SGML widget out and use it separately, and it's just not
possible with the current Midaswww architecture.

> VUIT: how did this get in there?

It (or something similar) is being used to generate UIL code for
Midaswww, which counts as another toolkit in my book, since I can't
effectively edit it by hand -- despite the fact I know Motif a lot
better than I'd like to, very little of my existing knowledge carries
over.

> NeXT: I'd drop X/Xt/Xaw for NextStep in a second if it was an
> option. NextStep isn't free, so it hasn't proliferated like X.
> That's pretty much the end of the story.

Agreed on all counts.  Again, my point.

I'm not arguing *against* special toolkits and builders in the
abstract -- I think they're great, for the lone programmer.  But it's
just plain a fact that there's nothing standardized about them;
they're not available on most systems; they're not going to make code
reusability practically possible, and their use causes too much
reinventing of the wheel.

Cheers,
Marc