W3C home > Mailing lists > Public > www-jigsaw@w3.org > November to December 1996

Re: Generating large amount of data

From: Sergej Melnik <melnik@aix520.informatik.uni-leipzig.de>
Date: Tue, 17 Dec 1996 19:42:16 +0100
Message-Id: <32B6E988.2969@aix520.informatik.uni-leipzig.de>
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.

Received on Tuesday, 17 December 1996 13:41:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:21 UTC