Re: LYNX-DEV USEMAP problems (was Re: fotemods.zip update)

[Klaus Weide]

On Sun, 13 Apr 1997, Foteos Macrides wrote:

> Klaus Weide <address@hidden> wrote:
> >[...]
> >It seems the ImageMap structured never get deleted (except at program
> >exit), and there is now way to "uncache" them.  This means that if
> >a map changes during the lifetime of a Lynx session (and the document
> >is reloaded), old (deleted) AREA entries will continue to show up.
> >I think this cold simply be improved if LYAddImageMap() would just
> >delete an ImageMap if it finds there already is one with the same 
> >address, and then create a new (empty) one, instead of reusing what
> >it finds.
> 
>       Whenever Lynx encounters a MAP in a document, it will be
> interpreted, and will replace any previous interpretation in the
                        ^^^^^^^
> ImageMap structure (note that I changed ImageMap to LYImageMap
> because I now access it outside of LYMap.c, i.e., in HTML.c),
> i.e., update it in the structure. 

But not totally replace - individual MapElement's will replace
a previous MapElement with the same address, but the ImageMap
list as a whole is not replaced.  As an example, take a local
copy of Scott's now-famous index2.html, and fix it up the way
you like it :) (move the MAP before the reference to it).
Let's forget the "where-to-look" complications, with your latest
code it should always be the local file.

Say your copy is ~/index2.html, do lynx ~/index2.html, then 'E'
for edit, change for example 

<area ... alt="Admissions & Enrollment" ... href="/admissions/">

into

<area ... alt="Admissions & Enrollment" ... href="/admission/">

save the file, exit editor, follow the "[menu]" LYNXIMGMAP link,
you now see two "Admissions & Enrollment" items.

> If it's not in the current
> document, i.e., if a link in the current document references a
> MAP in another document, and that other document was rendered
> previously such that the interpreted MAP is in the structure,
> Lynx should send an If-Modified-Since request to decide whether
> to use it or get the other document again and re-interpret the
> MAP.
> 
>       But If-Modified-Since requests aren't implemented in Lynx
> yet (Want a project? 8-).

Just a simple matter of using the new W3C Library :)

Oh, and of adapting it to Lynx's needs, and of finding all the bugs,
etc...

>  When implemented, they should also
> be sent before using any cached documents sought via forward
> links (as opposed to via the PREV_DOC command or History Page).
> That was one reason for my *adding* the Visited Links page, with
> forward links, rather than treating it as a replacement for the
> History Page.  The History Page links would still be treated
> like PREV_DOC commands, whereas those in the Visited Links page
> would invoke If-Modified-Since checks.

Ok, that is valuable insight into why things are the way they are.

By the way even proxy caches don't have to send IMS requests for
every client request (only when the cache entry isn't "fresh" any
more), so there's now reason why Lynx should do this unconditionally.
If it ever gets modified to send If-Modified-Since, but that's talking
about a lot of If's.

  Klaus


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