RE: HTBlackHole problem & dealing with stream return codes in HTTee
To: "'Henrik Frystyk Nielsen'" <firstname.lastname@example.org>
Subject: RE: HTBlackHole problem & dealing with stream return codes in HTTee
From: Maciej Puzio <email@example.com>
Date: Thu, 11 Jan 1996 15:21:02 +-100
Cc: "'WWW Library Mailing List'" <firstname.lastname@example.org>
From email@example.com Thu Jan 11 09: 11:49 1996
Thanks for your answer!
> Sorry for not answering _this_ mail before :-)
That's OK. I'm very glad that my mail didn't get into a HTBlackHole. :-)
To firstname.lastname@example.org readers:
If you don't know what I am writing about, please read previous mails.
This is a fourth level reply, so I had to cut all the original text to make
this mail readable. :-)
> I really would like to let HTBlackHole return HT_OK as it is a "neutral"
> return value that normally doesn't cause any reaction from the upstream
To be frank I have changed it in my copy of wwwlib to return HT_ERROR (I have
also changed HTTee implementation to take special care when HT_ERROR is
sent from a BlackHole). The result code is somewhat tricky, but works perfectly
well in my application. I haven't introduced any special result code (e.g.
HT_STOP_BLACKHOLE), as I suggested in my previous mail, because I wanted
to avoid making changes in the whole library (I don't get paid for that,
unfortunately :-( ). Still I think that a special result code is a good solution
(or perhaps it should be HT_ERROR or'ed with some special flag?)
> If the user has pushed
> "cancel" then there is really no more reason for continuing downloading the
> file (unless it goes in to some sort of shared cache). The stream prompting
> the user (HTSaveLocally) can therefore kill the request directly. This should
> work even if the instance of the HTSaveLocally stream is in fact a part of the
> request (however, testing it would be a good idea!). As the creation method
> for the HTSaveLocally gets passed the request object, it can immidiately call
> the HTRequest_kill() and then just exict when this call returns.
I think this could be a good solution in many situations (in mine too). But please
consider what would happen if HTSaveLocally stream were not a primary
> > [snip...snip...]
> > Here's the problem: bitflags [in stream return codes] won't allow you
> > to indicate the importance of each return code.
> But the upstream module can then check for both codes and then decide what to
> do... The important thing is that both codes (or in general all codes in case
> of multiple T streams) get propagated upstream.
I need to think about that.
> > My proposition:
> > [snip...snip...]
> > 2. Who knows what the importance of a stream is? The function which created it,
> > of course. So, the function which creates HTTee and then attaches two streams
> > to it should pass HTTee a special callback function as a parameter. This callback
> > function would be used for resolving the stream return codes conflicts. To ease
> > programming, HTTee should have a default resolving function, something similar to
> > merge_results in Hakon's version.
> Not a bad idea.
> The resolving function could also be a direct part of the
> upstream module which will be activated each time the T stream returns. As I
> see it, both ways will do, but maybe a callback function is a more flexibel
I've got a point of view on it, but I need to think a little.
I'll write to you soon.
Happy New Year!