LYNX-DEV Internal MIME types

[Klaus Weide]

On Fri, 25 Apr 1997, Christopher R. Maden wrote:

> [Klaus Weide]
> 
> > I still don't get where the "MIME type" part comes in.  (But maybe
> > that's because I don't know anything about DOM?  You may want to
> > spread soem more knowledge.)  But if this is about building a
> > structure in memory, which would just used by one application
> > (Lynx), what's wrong with pointers and linked lists etc. in C, what
> > does it have to do with MIME (internal or not).
> 
> By internal MIME type, I'm referring to Lynx's "www/source" and
> "www/present" objects.  I'm thinking of a new one, "xml/present".

The MIME-type-like "www/present" and "www/source" are not really used to
describe data structures.  That becomes more apparent when you consider
"www/download" which is their peer.  These three have more the character
of commands ("do this") than of media types ("this is").  Their use is an
artifact of using a mechanism (the WWW Library's StreamStack mechanism)
which wants everything expressed in terms of "convert this to that".  So
for saying "present this text/html document to the user" you have to say
"convert text/html to www/present", for saying "get this stuff into a
temporary file, then offer a menu of choices to the user" you have to say 
"convert to www/download".

But I assume your "xml/present" would label a data structure, not just
an endpoint or target for conversion, so it is different.

Why is it advantageous to build and keep in memory a whole document in
premasticated (parsed) form?  Specifically, for a program like Lynx.  Is
parsing such an expensive process?

I can see how this is useful or necessary if the structure will be
modified by the application, but Lynx is not an editing tool.
(I could come up with delayed processing of HTML tables, but I am curious
about a more general response.)

If I understand you correctly, you are talking about some structure in
memory that would be created by one stage of processing (parsing) and then
read by (an)other stage(s).  Those next stage(s) would have to traverse
the structure and generate (eventually, in the case of Lynx) calls to
functions of the display engine from it.  

The role of that data structure seems rather different from what MIME
types are used for in the Lynx code - where they are labels for the
current format of a sequence of octets streamed through a set of
"HTStream" stages (or for the target "format", see above).  Maybe you want
something less ephemeral, like a new "internal URL type"...  MIME types
are used to control what HTStream stages to put into a pipeline of them
(which then just handle calls feeding them data), while URL schemes
control which protocol module is the initial source of the data.  Protocol
modules are not restricted to handle what is fed them, sequentially, they
"go out and get things".

In any case, one has to have (a definition of) the structure, code to
build it up (a parser) and code to then walk through it and do something
with it, neither of which are decided upon or implemented (I am speaking
of Lynx here).  Nor is the usefulness of it established [at least not in
terms that I can understand :) ].  So it seems a bit premature to decide
now what to call it...

Just some musings and an attmpt to understand what you guys are talking
about.

> Pointers and linked lists are not exclusive with DOM. I was just 
> differentiating between our own off-the-cuff structure and one
> compliant with DOM; a DOM interface would be better because tools
> written to interface with DOM in MSIE or Netscape or Tango or Mosaic
> would be usable (or at least portable) to Lynx.

What useful things would those (hypothetical?) tools do for Lynx users?

How does it further the goals of the Web *Access* Initiative?


     Klaus

[  And I hope it is not a way to drag us all into an Internet-wide
   "Share your preference folder with our sponsors!" initiative...  ]

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;