lynx-dev internal pages (was: show list of statusline messages...)

[Leonid Pauzner]

19-Apr-99 11:46 Klaus Weide wrote:
> On Mon, 19 Apr 1999, Leonid Pauzner wrote:

>> * HTAlert, HTUserMsg and HTInfoMsg statusline messages now stored in a 
>> cyrcled
>>   buffer and accessible from the History Page as LYNXMESSAGES:/ link.
>>   This allow us to decrease the messages delay in lynx.cfg when we feel
>>   messages too annoying, but have a nice history list for diagnostic 
>> purposes.
>>   Idea belongs to Bela Lubkin. Buffer of 40 lines long. - LP

> I hope you don't mind if I comment on another piece of code I haven't
> tried yet... :)

> 1. There are basically thre ways to generate pseudo-documents (auxiliary
> screens, or whatever they should be called):
> A. Generate HTML in textual form, write it to temp file, then read in
>    temp file and treat as text/html.  Involves SGML.c with all its gory
>    details.
>    Examples: many, you must have used one :)
> B. Generate HTML in textual form, pass directly to (normally) SGML.c
>    (mostly via HTStreamStack).
>    Examples: LYHandleCookies(), LYLoadKeymap()
> C. Generate HTML structures (text, elements, attributes) on the fly, pass
>    directly to HTStructured object (i.e. HTML.c functions), bypassing
>    SGML.c.
>    Examples: files in WWW subdirectory (look for .c files having
>      #define PUTC(c) (*targetClass.put_character)(target, c)
>    or similar)

Thinking on A, B and C
I discover yet another possible way:

generate HTML in textual form and keep them in a memory chunk
or a temp file and assume this as source cache,
e.g. load it like we do in HTreparse_document() now.
That may be a little waste of memory (for sources) but looks a universal way
for doing such things, via (*...->put_string)(),
this makes temp file names hidden from the history page at least.

This is somehow similar to B but much easier and can be handled
in getfile() directly. From the other hand, new protocols used in B
allows keeping more complex things like LYNXCOOKIE://domain/ etc.
with different actions for different paths (like we need in forms options menu).

Just a thought.