W3C home > Mailing lists > Public > www-lib@w3.org > January to March 1996

Re: functionality of HTEventRequestTerminate

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Tue, 23 Jan 1996 17:52:21 -0500
Message-Id: <9601232252.AA05438@www20>
To: Erik Selberg <speed@cs.washington.edu>
Cc: www-lib@w3.org, frystyk@w3.org
Erik Selberg writes:
> I finally tracked down why my app has been appearing to be so
> sluggish... in the 4.0a6 release, we needed to define the function
> HTEventRequestTerminate, which would be called when a request was
> finished. This function was great, as it could be used to put the
> request into some sort of ready Q and then cause the HTEvent_Loop
> function to exit.

I know - that was a dictatorial discission from my point :-( However, I did 
some real thinking and this is my argument:

1) The return value exit solution using HTEventRequestTerminate() doesn't work 
well if using an external event loop. Especially if the event loop is used in 
other applications as well.

2) The solution was really a special example of a more generic problem: Both 
before and after a request has been issued, an application may want all kinds 
of functionality to be executed. Typical examples are

before:
	- cache check
	- proxy gatewaying
	- etc.

after
	- logging
	- history list
	- redirection		<- new in 4.0C
	- authentication	<- new in 4.0C 
	- etc.

The new Net callback API allows all of this and furthermore it reduces the 
Library core to be a registry for actions. This keeps the core independent of 
extending the set of actions to be executed. You can read more about the Net 
API at

	http://www.w3.org/pub/WWW/Library/User/Using/Net.html

> Unfortunately, there no longer appears to be any way to have the
> functionality of this beastie. I had incorrectly assumed that you now
> put this function, or another function like it, into the loop using
> HTNet_addAfter(). However, if HTEventRequestTerminate returns
> non-HT_OK, then it just cancels the string of callbacks. It does
> nothing to the actual event loop, which was the desired effect.

Another result of the Net callback API is that terminating a "thread" is now 
independent of terminating a request which means that threads may live longer 
than a single request. However, it also means that the application looses the 
ability of affecting the event loop in the NET call back functions - exactly 
as you describe.
 
> I've been digging around in the source, and so far I've been unable to
> come up with anything resembling what I need --- which is some
> callback / flag / thingy which, upon successfully loading a URL, quits
> the HTEvent_Loop. As near as I can see, the various __DoUserCallback
> calls will always return HT_OK unless a serious error, such as a
> memory outage or something, occur.

It would be reasonable to have a "event shutdown" function in the Event 
manager that simply exits the event loop and returns control to the 
application. Something like

	extern HTEvent_shutdown (void);

How this exactly is going to be implemented depends on the event loop.


-- 

Henrik Frystyk Nielsen, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA
Received on Tuesday, 23 January 1996 17:52:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:25 GMT