Re: returning info from streams in libwww
To: "Tom Gaskins" <firstname.lastname@example.org>
Subject: Re: returning info from streams in libwww
From: Henrik Frystyk Nielsen <email@example.com>
Date: Fri, 08 Dec 1995 10:15:41 -0500
From firstname.lastname@example.org Fri Dec 8 10: 24:42 1995
Reply-To: Henrik Frystyk Nielsen <email@example.com>
X-Mailer: exmh version 1.6.2 7/18/95
> Is there a best way for a stream to return information to the original request
> generator? In particular, I need to have a converter stream pass back a file
> name to the application, preferably via the request class itself.
A converter has a request object as part of the calling parameters and most
converters actually uses the request object for parsing information around. In
your case I would want to use the context part of the request object. There
are two methods for associating a application specific context object with a
extern void HTRequest_setContext (HTRequest * request, void * context);
extern void * HTRequest_context (HTRequest * request);
Here the application can add whatever it likes. You can see an example on how
to use the context object in the Line Mode Browser where it is used for
keeping the history list linear even though requests may return
"out-of-order". I believe this is very much the same as you are looking for.
> I could just have the stream call the application to convey such information,
> but in a threaded situation I'd need to match asynchronous calls with active
> requests. Ideally (I think) the stream would be able to add information to the
> request that the application could look for after loading if certain other
> conditions (success, content type, etc.) apply . Perhaps via something like the
> error stack, with each stream in a cascade able to push info onto stack.
One way to pass information is by using the Error object which can be
associated with a request object. The Error object is part of the HTError.html
module. However, the error object is more intended for handling information to
the user and not as much for handling information to the application.
> Alternatively, the application could pass parameters to the streams (perhaps
> via the request), similar to the client-data parameter of Xt callbacks. But I
> don't see any way to do this now short of defining the request's OutputStream
> and passing the parameters during the creation of that (and I'm still uncertain
> as to what the purpose and ramifications of specifying a request's OutputStream
> are, vs. defining a converter).
The request object is the best way of doing this!
> BTW: I'm really enjoying the new 4.x architecture.
I'm happy you like it. There will be some more "proof-of-concept" applications
shortly in order to have working examples of how the Library can be used.
Henrik Frystyk Nielsen, <firstname.lastname@example.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA