Re: Toward Graceful Deployment of Tables

Brian Behlendorf (brian@wired.com)
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:
> >[ylu@ccwf.cc.utexas.edu:]
> >
> >|>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
http://home.netscape.com/home/demo/1.1b1/tables/pricing.html, or
http://www.w3.org/hypertext/WWW/Arena/tour/tables2.html. 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.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/