Re: Toward Graceful Deployment of Tables

Brian Behlendorf (
Thu, 16 Mar 1995 10:16:54 -0800 (PST)

On Thu, 16 Mar 1995, Luke 路客 wrote:
> On Thu, 16 Mar 1995 Jon_Bosak@Novell.COM wrote:
> >[]
> >
> >|>future architecture. Inserting all kinds of garbage into the data
> >| ^^^^^^^^^^^^^^^^^^^^
> >|Unwarranted generalization.
> >
> >I was talking about the principles you were espousing rather than the
> >specifics of your proposal. The proposal might even have some merit;
> >the principles you were enunciating do not.
> There must be some misunderstanding here. My argument was 1) introducing
> format negotiation for table does not justify the cost and/or solve the
> problem. 2) an old net convention is useful in transition period and we
> should see it being applied appropriately. I am not advocating a paradigm
> shift.

Luke, why are you fighting so hard against content negotiation?? It's not a
"paradigm shift" at all. You're clearly willing to put effort into your
pages to make them viewable by everyone - why cramming all that into one
index.html file is better than creating two logically correct pages and
naming them index.html and index.html3 is beyond me (though I see you're
running NCSA 1.3 which doesn't yet have native content-negotiation (very
soon, though!), but you should still be able to hack up a CGI script to
look at the HTTP_ACCEPT envvar).

> >guess that the great majority of people coming into this for the first
> >time feel pretty much the way that you do, like student programmers
> >who don't see why "purists" insist that it's better to write
> >structured code. (You may not see the analogy, but those of us who
> >were around twenty years ago when inspired spaghetti code was the norm
> >remember that that was exactly the way that even the professional
> >programmers felt about it.) Certain kinds of constraints make sense
> >only when your projects reach a certain size. Until then, you don't
> >see the point, and it's hard for others to explain it to you.
> I happen to understand this (I think :). As I see it, the history of
> software engineering is a evolutionary history of management of dependency
> and reusability. What purists can't see is that there is a trade off
> between the scale/granularity of abstraction and the cost of abstraction
> maintenance.

"Abstraction maintenance"? I'd argue that inabstraction results in far
higher amounts of work to maintain.

> >Today I put 28,000 pages of material online, bringing the total I have
> >put on our Pubs Web server over the last few weeks to somewhere in the
> >neighborhood of 110,000 pages. This task, based on five years of
> >development, would have been quite impossible if the material had been
> >tagged according to the ideas you are promoting. Unfortunately, I
> Good for you -- that's really an awesome job. On the other hand if your
> page generating software is written in a modular way, it's trivial to add
> compatible table support as in my examples in the table generator. If this
> is not trivial, it would imply a bad design in your page editing/management
> software.

Your solution is NOT generally applicable. It worked for your limited
case on your home page, it wouldn't work for something like, or Some of us
would rather not have everything in a table as PRE. It also makes
it very hard to build pages where tables could be sucked into a
spreadsheet application like Excel usefully.

I guess I've run out of energy on this topic. Maybe this is one of
life's "either you get it or you don't", a fight that can also be
portrayed as "old guard vs. new energetic upstarts" or "conventional
wisdom vs. new thinking" or "efficacy vs. correctness", and those are
argumental dead ends.