- From: Sergej Melnik <melnik@aix520.informatik.uni-leipzig.de>
- Date: Tue, 17 Dec 1996 19:42:16 +0100
- To: Anselm Baird-Smith <abaird@w3.org>
- Cc: www-jigsaw@w3.org
Anselm Baird_Smith wrote: > ... > I am wondering why you need a thread in your case, it would probably > be better (as far as I understand) to write a subclass of InputStream > that takes your database as a "parameter" (whatever this means), and > which generates the client output on the 'read' method (this is used, > for example in the SSI resource). When Jigsaw detects a close on the > client socket it will close your stream (call its close method), at > which time you can do any cleanup. In my case the output is generated recursively using a tree structure which resides in an object-oriented database. So it is hard to deliver data on demand when the client is ready to consume it because I cannot simply forward incoming read requests to yet another input stream as it seems to be done in SSIStream.read() implementation. That's why I pass an output stream to a separate thread which continuously fills it up. > The next release of Jigsaw adds a w3c.jigsaw.http.Client:isInterrupted > method that you can also call during processing to check whether the > client has closed the connection or not (if you implement my above > suggestion, I don't think you need it though). I'll be happy to use this method. However, the user will still be forced to care about killing such running threads himself/herself. Why not giving an option that the client notifies some registered "Observer"s when the connection is broken? > Hope this helps, > Anselm. Thank you, it does. --serge
Received on Tuesday, 17 December 1996 13:41:42 UTC