RE: HTBlackHole problem & dealing with stream return codes in HTTee
To: "'Daniel W. Connolly'" <email@example.com>
Subject: RE: HTBlackHole problem & dealing with stream return codes in HTTee
From: Maciej Puzio <firstname.lastname@example.org>
Date: Wed, 20 Dec 1995 18:05:14 +-100
Cc: "'WWW Library Mailing List'" <email@example.com>
From firstname.lastname@example.org Wed Dec 20 12: 14:10 1995
Thanks for answer. I'm sorry to say that, but I can't agree with all your suggestions.
> Err... that would make the blackhole useless for its sole purpose: to
> consume the data.
Do we really need the stream which _only_ consumes data? What for? If the data
is not needed, we should stop pumping it into the stream. The blackhole _should_
NOTIFY its caller(s) that the data is no longer needed. Of course, if the caller doesn't
have any way to stop pumping the data (or is dumb or is HTTee), it would ignore the
The new blackhole WILL consume the data, as it is now, but in the same time it will
shout upstream: "All of you there! You CAN stop sending the data! It gets discarded
> It seems like the problem is that the HTSaveLocally() uses the black hole
> in the first place -- it's not consuming the data, but rejecting it.
> If HTAlert fails, HTSaveLocally should return an error
Hmmm... This is even a better idea than mine. I was also thinking about that, but
I'm not sure whether this would not interfere with the rest of the library. HTBlackHole
is de facto a "stream NULL". What would happen if some functions begin returning
NULL pointers instead of working streams?
But on the other hand, this is the right direction, I agree.
> (or a new kinds of stream that reports HT_ERROR all the time), no?
Of course, we can introduce a new stream and use it in HTSaveLocally(), but why
not do it in the whole library?