Re: Frames and Documents (fwd)

\\ | Could it be the awkwardness of addressing instances of frame states
\\ | is one of the reasons people say frames are kludgy? Personnally, I
\\ | very much would prefer that the whole concept of frames was thought
\\ | about first, (and redone), before accepting complicated kludges.

Agreed, but the way things have been going lately I doubt that will
happen. A lot of browsers already have implemented frames, unfortunately,
while completely ignoring the fact that most of that functionality can be
provided by alternate (and better, IMHO) methods. Anything more complex
frames can't do very well anyway, so coming up with an alternate structure
would be desirable. (For instance, a reference cannot update documents in
two frames simultaneously, it takes a script to perform that task.)

\\ Over-engineering of solutions has not been a common problem in the
\\ evolution of the Web...
\\ 
\\ Consider that we still haven't handled a couple of key shortcomings of
\\ the whole URL model:
\\ 
\\ 	the tying of a resource name to a specific host, (making it
\\ 	impossible (or kludgy) to migrate it elsewhere or to replicate
\\ 	it

I don't understand why this is desirable. There are a lot of proxy caches
out there that would not be as effective if the URL were tied down to one
server. Perhaps you mean the origin server of a URL should always be
recorded. That still looks like it would be impossible to guarantee, unless
we put a great deal of faith into the software authors that they would
either not modify the content or keep a record of the origin server at all
times.

\\ 	providing access only to author-provided TARGETs within a
\\ 	resource makes it impossible for an author to cite arbitrary
\\ 	places, tossing away centuries of standard citation practice

The only reasonable way I can think of for this is to record the byte
offset in the URL. Any other method would in fact involve modifying the
source document (or a copy of it). Then keeping track of what changed in
the source would be impossible for the person that had liked to some
portion of the document, which means an additional effort in keeping track
of how modifications effected the reference. This is just as true if the
byte offset idea were replaced by id's for each element.

While both objections to the current URL model are perfectly valid, I don't
think there is much we can do about them right now. However, frame
references is another problem entirely, and can be fixed if we take a
ground up approach. Not that I think that will happen...

\\ It's hardly surprising that the first sketchy approach to presenting
\\ configurations of resources as logical entities would be
\\ under-engineered and would last forever...

I think the primary problem with frames and URL's for them is that framed
pages inherently create state, while URL's were never intended to represent
state. Forcing a state representation into a URL is most definitely a
kluge. One may conceivably draw an analogy between a CGI script (search URL
specifically) and a frame URL, and provide arguments for the framed
page. But the arguments model shall also have to be extended to include
framesets within a frame. That would be like giving to a CGI as an argument
another CGI with arguments for that, nesting infinitely. A grouping
mechanism (equivalent of parentheses) becomes necessary.

This to me is far more appealing than representing frame sub-documents as
array references.

Sunil

Received on Tuesday, 10 September 1996 17:51:14 UTC