Re: Memory Cache handler
To: moi <firstname.lastname@example.org>
Subject: Re: Memory Cache handler
From: Henrik Frystyk Nielsen <email@example.com>
Date: Wed, 10 Jan 1996 21:50:42 -0500
Cc: "'firstname.lastname@example.org'" <email@example.com>
From firstname.lastname@example.org Wed Jan 10 21: 55:09 1996
Reply-To: Henrik Frystyk Nielsen <email@example.com>
X-Mailer: exmh version 1.6.2 7/18/95
> I would like to use the memory cache manager but don't understand what I must implement.
The anchor object contains a void pointer which is called "document" which can
be manipulated through the methods
extern void HTAnchor_setDocument (HTParentAnchor *me, void * doc);
extern void * HTAnchor_document (HTParentAnchor *me);
The document pointer can point to a data object which represents some kind of
rendition of the object represented by the anchor object. For example, the
anchor object can represent the document identified by the URL:
When this document is fetched via HTTP then the application can build an
object in memory representing the parsed version of the document and assign it
to the anchor object using the methods above. The Line Mode browser uses the
HText interface to build the parsed object which is done in the GridText.c
module in the Line Mode browser code.
However, any HTML parser can build an object in memory and assign it to the
anchor object - it doesn't even have to be parsed, it can in fact be the raw
data object as received from the remote HTTP server. The latter is interesting
in a server application where a small memory cache can keep the most used
documents so that they can be served immediately. You can find more
information about the HText interface in the User's guide at
The application can register any number of callback functions to be called
before the Library actually starts a HTTP request (of course you can also
register functions to be called _after_ the request has been done). This is
done through the HTNet interface using the methods:
extern BOOL HTNetCall_addBefore (HTNetCallback *cbf, int status);
extern BOOL HTNet_setBefore (HTList * list);
extern HTList * HTNet_before (void);
extern int HTNet_callBefore (HTRequest *request, int status);
extern BOOL HTNetCall_addAfter (HTNetCallback *cbf, int status);
extern BOOL HTNet_setAfter (HTList * list);
extern HTList * HTNet_after (void);
extern int HTNet_callAfter (HTRequest *request, int status);
The Library provides two implementations of this that an application can use
(or it can use its own instead or none at all). They are called HTLoadStart()
and HTLoadTerminate() and can be found in the HTHome module in the Library.
The LoadStart() function calls a memory cache handler to see if the object is
already present. In the case of the Line Mode Browser it's the function
HTMemoryCache() in GridText.c.
> The example in linemode browser use an HText_select function but i don't see what it really does.
> And what to do if some of the request are inline images ?
As the line mode browser doesn't support inlined images I can't show you an
example, but it still works the same way. There is no reason why the data
object associated with an anchor can't be a gif image, the anchor itself
contains all the information needed to distringuish the data object (media
type, language, content length etc.)
> For what i have seen, it seems that when you return HT_LOADED from the cache handler nothing more is
> done... so how to associate your real object to the result of your request ?
Through the anchor object. The anchor object is pointed to by the request
object. The request object only lives as long as the request is running
whereas the anchor object normally stays around much longer (often for the
rest of the lifetime of the application).
Henrik Frystyk Nielsen, <firstname.lastname@example.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA