RE: HTBlackHole problem & dealing with stream return codes in HTTee

Hi!

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 
notification.

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
here!"

> 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?


Maciej Puzio
puzio@laser.mimuw.edu.pl

Received on Wednesday, 20 December 1995 12:14:10 UTC